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I.  INTRODUCTION 


A.  PURPOSE 

The  purpose  of  this  research  paper  is  to  investigate  whether  Levels  of  Information 
Systems  Interoperability  (LISI),  a  computer  software  process,  can  improve  Department  of 
Defense  (DOD)  Command,  Control,  Communications,  Computers,  and  Intelligence  (C4I) 
systems’  interoperability.  This  is  accomplished  by  researching  the  development  of  LISI 
and  analyzing  why  LISI  was  implemented,  what  the  elements  of  LISI  capabilities  model 
are,  how  the  LISI  process  works,  and  whether  it  can  actually  improve  the  interoperability. 

B.  BACKGROUND 

Command,  Control,  Communications,  Computers,  and  Intelligence  (C4I)  systems 
relay  critical  information  to  U.S.  forces  during  joint  operations.  If  joint  operations  are  to 
be  successful,  C4I  systems  must  be  ’’interoperable,”  i.e.,  capable  of  exchanging 
information  and  operating  effectively  together.  However,  the  military  services  have  a 
long  history  of  interoperability  problems  during  joint  operations.  For  example,  the 
success  of  the  Persian  Gulf  War  in  1991,  a  major  joint  military  operation,  was  hampered 
by  a  lack  of  basic  interoperability.  Since  then,  the  DOD  has  had  a  number  of  initiatives 
to  address  various  aspects  of  interoperability  including  Joint  Tactical  Architecture, 
Defense  Information  Infrastructure/Common  Operating  Environment  (DII/COE),  DII 
Master  Plan,  Shared  Data  Environment  (SHADE),  Joint  Battle  Center  (JBC),  Joint 
Interoperability  Test  Command  (JITC). 

Commencing  in  1993,  LISI  has  continued  to  advance  in  capability  through  several 
phases.  The  “Exploratory  Phase”  in  1994  consisted  of  an  initial  assessment  for  Joint 
Task  Force  Operations  in  support  of  the  Intelligence  Systems  Council  (ISC).  During  the 
“Analysis  Phase”  in  1996,  the  LISI  Maturity  Model  and  assessment  process  was 
developed.  The  “Proof  of  Concept  Phase”  in  1997  began  to  implement  the  process  with 
an  automated  prototype  and  examined  the  LISI  capability  through  a  set  of  preliminary 
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tests.  During  the  FY99  “Development  Phase,”  six  organizations  to  include  the  U.  S. 
Army  Program  Executive  Office,  Command,  Control,  and  Communications  (PEO  C3S) 
examined  and  tested  the  prototype  for  its  utility  in  assessing  and  potential  for  identifying 
ways  of  improving  interoperability.  The  1999  “Development  Phase”  was  accelerated  as 
the  result  of  the  U.  S.  General  Accounting  Office  (GAO)  audit  report:  Joint  Military 
Operations:  Weaknesses  in  DOD’s  Process  for  Certifying  C4I  systems’  Interoperability. 

My  personal  interest  in  the  area  of  information  system  interoperability  started  in 
August  1997  when  I  joined  PEO  C3S.  As  a  member  of  the  1997  inaugural  Competitive 
Development  Group  (CDG),  I  was  assigned  in  PEO  C3S  to  commence  my  three  years  of 
cross- functional  and  leadership  training.  The  fifty- plus  mission  critical  C3S  systems 
under  that  PEO  overwhelmed  me  after  my  previous  10  years  of  program  management 
experience  mainly  in  business  and  financial  management.  I  often  wondered  how  these 
systems  interoperate  and  fit  into  the  Army  Battle  Command  Systems  (ABCS)  to  support 
DOD’s  First  Digital  Division  (FDD).  Even  without  strong  background  in  the  area  of 
information  systems,  I  put  down  “Interoperability”  as  my  planned  thesis  consideration  on 
my  Naval  Postgraduate  School  application  form  without  any  hesitation. 

Working  in  the  Horizontal  Technology  Integration  Office  (HTIO),  PEO  C3S,  I 
was  privileged  to  have  firsthand  information  on  LISI  progress  and  to  have  Mr.  Tony 
Kunsaitis  as  my  associate  thesis  advisor.  Tony  is  the  Interoperability  Manager  for  PEO 
C3S,  and  this  PEO  was  the  first  in  the  Army  to  be  involved  in  the  LISI  efforts.  Although 
LISI  was  initiated  in  1993,  it  is  still  foreign  for  the  majority  of  the  program  management 
community.  My  original  discussion  with  Mr.  Kunsaitis  about  this  thesis  was  to 
concentrate  on  how  useful  LISI  would  be  to  the  Program  Managers,  and  I  hoped  to 
convince  the  Program  Managers  to  choose  LISI  as  their  interoperability  tool.  However,  a 
memo  signed  by  both  LTG  Peter  M.  Cuviello  and  LTG  Paul  J.  Kem  to  mandate  the  use 
of  LISI  changed  my  thesis  concentration.  Since  the  Program  Managers  do  not  have  a 
choice  but  to  use  LISI,  I  believe  that  it  would  be  more  beneficial  to  research  whether 
using  LISI  can  actually  improve  the  interoperability,  and  if  any  improvements  of  LISI 
can  be  made.  Therefore,  the  purpose  of  this  study  is  to  examine  whether  LISI  can 
improve  information  systems’  interoperability. 
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C.  RESEARCH  QUESTIONS 


1.  Prime  Research  Question 

Can  Levels  of  Information  System  Interoperability  (LISI),  a  computer  software 
applications  and  database  with  associated  processes,  improve  DOD  C4I  systems’ 
interoperability? 

2.  Subsidiary  Research  Questions 

1.  What  is  LISI? 

2.  What  are  central  elements  of  LISI  and  associated  process? 

3.  What  are  the  motivations  to  implement  LISI? 

4.  How  does  LISI  process  work? 

5.  Is  the  LISI  system  secured? 

6.  Is  the  LISI  system  user-friendly? 

7.  Can  LISI  improve  DOD  C4I  systems’  interoperability? 

D.  SCOPE 

There  are  five  factors  that  have  shaped  the  scope  of  my  thesis.  First,  I  am 
personally  interested  in  information  system  interoperability.  Second,  there  are  GAO- 
reported  weaknesses  in  DOD’s  process  for  certifying  C4I  systems’  interoperability. 
Third,  MITRE  claims  that  LISI  is  the  only  DOD  interoperability  improvement  initiative 
that  can  fill  in  the  gaps  between  all  the  other  initiatives,  whether  taken  individually  or 
collectively.  Fourth,  a  pilot  assessment  of  the  LISI  has  been  completed,  using 
components  of  the  Army  Battle  Command  System  (ABCS).  Last  but  not  least,  the  use  of 
LISI  has  become  mandatory.  Therefore,  the  scope  of  the  thesis  is  framed  in  how  LISI  can 
be  used  and  how  it  can  be  improved,  not  whether  LISI  should  be  used. 
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E.  METHODOLOGY 


After  deciding  that  I  would  write  about  information  system  interoperability,  and 
hearing  that  LISI  could  be  the  solution  for  interoperability  impimemcnt,  I  started  asking 
Mr.  Kunsaitis  a  lot  of  questions  about  interoperability  and  the  details  of  the  LISI 
progress.  I  browsed  through  the  LISI  report  of  October  1999  after  MITRE  completed  its 
pilot  assessment  of  the  LISI  using  data  on  components  of  the  ABCS.  I  gained  the  overall 
knowledge  on  what  LISI  actually  is  about  and  what  its  process  and  execution  involve.  I 
had  my  thesis  originally  planned  to  show  how  the  LISI  can  help  the  PMs  and  hopefully  to 
convince  them  to  use  the  LISI.  When  the  use  of  LISI  became  mandatory,  the  need  to 
convince  the  PMs  to  utilize  LISI  remains,  but  I  believe  that  it  is  more  prudent  to  research 
if  LISI  can  actually  improve  interoperability,  if  any  modification  of  LISI  can  further 
improve  the  interoperability,  and  not  whether  LISI  should  be  used. 

The  MITRE  Corporation  has  been  the  LISI  developer  for  the  Army  since  1993. 

To  further  support  the  Army  System  Engineering  Office  (ASEO)  and  Horizontal 
Technology  Integration  (HTIO),  PEO  C3S,  MITRE  delivered  and  configured  a  Prototype 
server  at  HTIO,  PEO  C3S.  MITRE  conducted  a  pilot  LISI  assessment  of  a  selected 
subset  of  ABCS  components  in  1999.  In  early  coordination  discussions  MITRE 
concluded  that  three  systems  about  the  complexity  of  the  All  Source  Analysis  System 
(ASAS)  would  be  a  workable  analysis  for  the  effort  to  recommend  changes  to  the  data 
collection  capability  of  LISI.  Following  that,  the  assessment  of  a  full  set  of  10  to  11 
ABCS  component  systems  was  completed.  The  LISI  data  collection  (survey)  portion  of 
the  prototype  was  developed  to  collect  information  about  a  system  through  the  use  of  a 
common  web-based  browser  as  the  interface.  Once  the  information  is  entered,  the 
prototype  applies  the  four  levels,  four  parameter  LISI  paradigm  to  produce  the 
interoperability  profile  of  a  system.  This  yields  a  quantitative  measure  of  a  system’s  (or 
interfaces’)  interoperability  potential.  The  result  of  this  pilot  assessment  of  the  LISI  was 
reported  in  October  1999  by  MITRE. 
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F.  ORGANIZATION  OF  THE  STUDY 


Chapter  II  provides  an  overview  of  LISI,  its  elements,  and  its  associated  process. 
Chapter  II  also  introduces  the  motivations  to  implement  LISI  in  term  of  information 
sy  stems  ’  interoperability . 

Chapter  III  illustrates  how  LISI  process  works  by  discussing  the  development  and 
use  of  the  LISI  prototype  tool  in  its  application  to  Army  Systems.  Next  it  examines  the 
LISI  user  friendliness  and  its  security. 

Chapter  IV  provides  analysis  of  the  primary  research  question  as  whether  LISI 
can  improve  DOD  C4I  systems’  interoperability.  The  reports  from  the  LISI  pilot 
assessment  conducted  by  MITRE  in  1999  and  the  final  analysis  assessed  by  HTIO 
Interoperability  in  2001  were  used  for  the  analysis. 

Chapter  V  summarizes  the  findings  of  the  research,  answers  the  research 
questions,  and  presents  recommendations  for  further  research  and  study. 

G.  BENEFITS  OF  THE  S  TUDY 

It  is  my  hope  that  this  study  will  be  used  to  continue  the  evolution,  refinement, 
application,  and  institutionalization  of  LISI  because  applying  LISI  may  benefit  the 
following: 

Joint  Mission  Planners  -  who  need  to  be  able  to  use  LISI  in  context  with  mission  area 
assessments  to  facilitate  the  development  and  dissemination  of  interoperability 
requirements  for  new  systems. 

Program  Managers  -  who  need  to  be  able  to  use  LISI  to  identify  potential  interoperability 
problems  early  in  the  analysis  phase  of  system  development  (the  period  during  which 
implementation  choices  are  made)  rather  than  discovering  issues  after  system  fielding. 
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Command  Architects  -  who  need  to  be  able  to  use  LISI  to  assess  the  interoperability  of 
systems  in  an  existing  or  planned  architecture,  to  evaluate  alternative  strategies,  to 
improve  interoperability,  and  to  meet  the  mission  and  operational  requirements. 

Joint  Task  Force  (JTF)  Planner  -  who  needs  to  be  able  to  use  LISI  to  assess  the 
interoperability  of  existing  systems  prior  to  deployment,  including  the  rapid  identification 
and  resolution  of  interoperability  shortfalls. 

System  Evaluators  -  who  need  to  be  able  to  use  LISI  during  laboratory  or  field 
experimentation  to  determine  the  impact  of  various  interoperability  levels  on  mission 
effectiveness. 
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II.  WHAT  IS  LISI? 


A.  INTRODUCTION 

Although  LISI  was  initiated  in  1993,  it  is  still  foreign  to  the  majority  of  the 
program  management  community.  In  order  to  examine  how  LISI  can  improve  DOD  C4I 
systems’  interoperability,  it  is  prudent  to  know  exactly  what  LISI  means  and  what  its 
functionalities  are  and  how  LISI  actually  works.  This  Chapter  will  exam  the  “What’s” 
and  Chapter  III  will  discuss  the  “How’s.”  The  following  sections  give  a  description  and 
background  information  on  LISI,  its  evolution,  its  elements,  and  its  benefits  of 
implementation.  Also,  other  DOD  Information  Technology  (IT)  initiatives  are  discussed 
in  relation  to  LISI. 

Much  of  the  information  presented  in  this  chapter  was  extracted  and  summarized 
from  several  information  interoperability  and  LISI  related  reports  and  briefings.  The 
reports  include  GAO  report  of  March  1998  on  Joint  Military  Operations,  C4I 
Surveillance  and  Reconnaissance  (C4ISR)  Architectures  Working  Group  Final  Report  of 
14  April  1998,  and  Pilot  Assessment  of  the  LISI  Using  Components  of  the  ABCS  Final 
Report  of  November  1999.  The  briefings  include  Army  LISI  Overview  Briefings  of  12 
October  2000  from  Department  of  Army  Military  Office  -  Directorate  of  Integration 
(DAMO-DOI);  Defense  Information  Systems  Agency  -  Joint  C4  Program  Assessment 
Tools  (DISA-JCPAT);  Office  of  the  Secretary  of  Defense  -  Assistant  Secretary  of 
Defense  Command,  Control,  Communications  and  Intelligence  (OSD- AS  D  C3I);  and  the 
Army.  Detailed  information  from  each  of  these  Army  briefings  is  now  available  at 
http://sysarch.army.mil/LISI  Inspector/references. 

B.  LISI  DEFINITION  AND  FUNCTIONALITIES 

LISI  can  be  defined  as  a  formal  Reference  Model,  an  assessment 
implementation  of  the  interoperability  maturity  model,  and  a  structured  process  for 
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improving  interoperability  between  varied  information  systems .  Simply  said,  LISI  is 
a  maturity  model  and  interactive  process  for  assessing  and  improving  interoperability. 

The  LISI  tool  provides  an  automated,  web-based  interoperability  assessment 
capability.  It  provides  interoperability  analysis,  such  as  interoperability  profiles  for 
C4ISR  information  technology  (IT)  systems,  interface  status  between  systems  at  nodes  or 
within  a  mission  area,  and  end-to-end  interoperability  levels  for  a  specific  mission.  It  is 
intended  to  support  system  of  systems  interoperability  and  requirements  assessments 
across  the  Department  of  Defense. 

By  dissecting  the  above  definition  and  description,  the  functionalities  of  LISI  can 
be  summarized  as:  (Levine,  2000) 

a.  A  discipline  for  improving  interoperability  (It  is  a  formal  process.) 

b.  A  work  ethic  for  improving  interoperability  (It  requires  collective 
commitment  to  a  process.) 

c.  A  structured  approach  for  reaching  agreement  about  what 
capabilities  are  needed  to  improve  interoperability  (It  involves 
common  understanding  of  how  to  implement  a  process.) 

d.  A  measure  of  performance  for  interoperability  that  characterizes 
what  capabilities  can  be  performed  between  systems  (It  is  expressed  in 
“levels”  of  increasing  sophistication.) 

However,  LISI  is  not  a  prescription  for  guaranteeing  interoperability.  The  heart 
of  the  LISI  concept  is  the  formulation  of  a  system  “profile”  which  was  created  by  LISI. 
The  “profile”  may  become  the  common  denominator  for  determining  interoperability 
between  C4  systems  but  it  is  certainly  not  a  prescription  for  guaranteeing 
interoperability.  The  profile  is  an  indicator  and  not  an  absolute.  The  reason  is  simply 
that  “garbage  in  and  garbage  out”  and  the  system  can  only  be  as  good  as  the  data.  The 
questionnaires  used  for  the  process  may  not  be  inclusive  of  all  pertinent  interoperability 
elements  required.  Furthermore,  the  person  entering  the  data  for  the  questionnaires  might 
be  not  knowledgeable  enough  to  answer  all  the  right  questions  with  the  correct  answers. 
Therefore,  LISI  is  a  tool  to  examine,  to  compare,  but  not  to  guarantee  the  interoperability 
of  IT  systems. 
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C.  MOTIVATION  OF  INITIATING  AND  IMPLEMENTING  LISI 


1.  Achieve  Information  Superiority 

The  Chairman  of  the  Joint  Chiefs  of  Staff  advanced  a  bold  vision  of  American 
war  fighting  capabilities,  Joint  Vision  2010,  which  has  become  the  conceptual  template 
for  how  we  will  channel  the  vitality  of  our  people  and  leverage  technological 
opportunities  to  achieve  new  levels  of  effectiveness  in  joint  war  fighting.  (Shalikashvili, 
1997)  At  the  heart  of  the  joint  vision  is  information  superiority  -  the  ability  to  collect 
and  distribute  to  U.S.  forces  throughout  the  battlefield  an  uninterrupted  flow  of 
information,  while  denying  the  enemy’s  ability  to  do  the  same.  (Cohen,  1997)  The 
Quadrennial  Defense  Review  (QDR)  of  May  1997  also  identified  information 
superiority  as  the  backbone  of  Military  Innovation,  and  noted  that  the  Revolution  in 
Military  Affairs  (RMA)  centers  on  developing  the  improved  information,  and  command 
and  control  capabilities  needed  to  significantly  enhance  joint  operations. 

In  order  to  provide  uninterrupted  flow  of  information  during  the  military  joint 
operations,  the  C4I  systems  must  be  “interoperable.”  Unfortunately,  the  military  services 
have  a  long  history  of  interoperability  problems  during  joint  operations.  LISI  was 
initiated  in  1993  after  the  difficulties  of  basic  interoperability  experienced  during  the 
Persian  Gulf  War  in  1991.  The  information  superiority  envisioned  by  Joint  Vision  2010 
in  1997  further  challenged  the  development  and  implementation  of  LISI. 

2.  Support  Joint  Task  Force  (JTF) 

The  JTF  that  fights  the  next  conflict  does  not  exist  until  the  need  arises.  Its 
approach  to  information  management  and  the  set  of  electronic  information  systems  will 
be  based  in  large  part  on  which  Services  is  in  charge  of  the  operation.  Though  all 
Services  provide  their  essential  set  of  automated  “tools,”  the  particulars  of  which  ones, 
how  many,  where  they  are  located,  etc.  are  all  dependent  on  the  situation  and  the 
decisions  of  the  assigned  Service  Commander  or  someone  in  his  chain  of  command. 
Determining  how  these  systems  are  pulled  together  to  accomplish  a  joint  mission  is  of 
one  of  the  major  challenges  facing  the  development  of  information  system  architectures 
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throughout  DOD.  Information  systems  built  to  meet  specific  Service  requirements  must 
still  provide  for  the  appropriate  level  of  C4ISR  interoperability  to  meet  joint 
requirements.  Therefore,  understanding  how  much  interoperability  is  required  is  a  key 
consideration  that  must  be  accounted  for  when  designing  constructing,  and  deploying  IT 
architecture. 

In  order  to  support  JTF,  LISI  has  been  designed  to  focus  on  defining  and 
assessing  systems  against  increasing  levels  of  sophistication  for  system- to- system 
interaction.  These  levels  describe  the  stages  of  process  improvement  for  interoperability 
and  are  documented  in  the  form  of  an  Interoperability  Maturity  Model. 

3.  Compliance  With  Information  Technology  Management  Reform  Act 
(ITMRA) 

The  ITMRA  of  1996  (Public  Law  104-106),  also  know  as  the  Clinger-Cohen  Act, 
requires  the  Federal  government  to  develop  “a  process  and  procedure  for  establishing 
goals  for  improving  the  efficiency  and  effectiveness  of  government  agencies’  operations 
and  the  ability  to  deliver  goods  and  services  to  the  public  using  information  technology. 
The  goals  must  be  “measurable.”  (C4ISR,  1998) 

The  ITMRA  further  states  that,  “the  director  shall  encourage  the  use  of 
performance-based  and  results-based  management.”  Before  LISI,  there  were  no  widely 
accepted  performance-based  and  results-based  standards  for  interoperability.  Now  LISI 
directly  supports  the  development  of  IT  architectures  within  the  context  of  ITMRA  by 
assessing  the  level  of  interoperability  required  and  attained  between  systems.  (C4ISR, 
1998) 


4.  Assist  in  Certifying  Process  And  Improving  C4I  systems’ 
Interoperability 

GAO  identified  several  weaknesses  in  DOD’s  process  for  certifying  C4I  systems’ 
interoperability  in  its  March  1998  report.  The  Joint  Staff’s  Director  for  C4  systems  (J-6) 
is  assigned  primary  responsibility  for  ensuring  compliance  with  certification  requirement. 
Certification  is  intended  to  help  provide  the  war  fighter  with  C4I  systems  that  are 
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interoperable  and  to  enable  forces  to  exchange  information  effectively  during  a  joint 
mission.  However,  DOD  did  not  have  an  effective  process  for  certifying  existing,  newly 
developed,  and  modified  C4I  systems  for  interoperability.  As  a  result,  many  C4I  systems 
have  not  been  certified  for  interoperability  and  DOD  did  not  even  know  how  many 
require  certifications.  (GAO,  1998) 

GAO  warned  that  improving  ways  of  complying  with  the  certification  process 
alone  would  not  solve  all  of  the  issues  related  to  interoperability  and  a  number  of 
initiatives  had  to  be  continued.  LISI  was  one  of  the  initiatives  mentioned  in  the  report. 
GAO  indicated,  “DOD’s  1993  LISI  initiative  is  to  improve  C4  and  intelligence  systems’ 
interoperability.  System  developers  are  to  use  this  tool  to  assess  interoperability, 
determine  capabilities  needed  to  support  system  development,  and  determine  the  degree 
of  interoperability  needed  between  C4I  and  other  systems.”  (GAO,  2000) 

5.  Become  A  Mandatory  Interoperability  Evaluation  Tool 

In  recognizing  that  the  Army  lacks  a  means  to  quickly  assess  System-0 f-Systems 
(SoS),  the  Director  of  Information  Systems  for  C4  and  the  Military  Deputy  to  the 
Assistant  Secretary  of  the  Army  (Acquisition,  Logistics  and  Technology)  mandated  on 
their  joint  memorandum  of  15  August  2000  that  the  Headquarters  of  Department  of  Army 
(HQDA)  to  employ  LISI  framework  and  its  associated  interoperability  assessment  tool  to 
address  SoS  interoperability. 

The  memorandum  further  explained  the  rational  for  mandating  of  implementing 
LISI.  Chairman  Joint  Chiefs  of  Staff  Instruction,  6212.01B,  dated  May  8,  2000,  calls  for 
the  development  of  the  Command,  Control,  Communications,  Computers  and 
Intelligence  Support  Plan  (C4ISP).  A  C4ISP  must  be  developed  for  all  systems  that 
exchange  information  in  any  electronic  form.  The  technical  data  stored  in  LISI,  along 
with  LISI  output  products,  satisfy  the  C4ISP  requirements  for  a  technical  architecture 
profile  and  view.  Therefore,  using  LISI  to  meet  this  requirement  gives  the  Army  a 
standard,  mature  process  to  collect,  archive,  and  share  this  information.  (Cuviello,  2000) 
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D.  EVOLUTION  OF  LISI 


LISI  has  come  a  long  way  to  today’s  pilot  assessments  and  implementation. 
MITRE  Corporation  has  been  the  developer  of  the  LISI  process  and  its  associated 
software  application  since  the  inception  of  LISI  in  1993.  It  is  a  process  that  has  evolved 
since  its  inception  in  1993.  The  Intelligence  Systems  Council  (ISC)  conducted  the  initial 
concept  and  process.  Then  Integration  Task  Lorce  (ITL)  expanded  and  detailed  the  LISI 
concept  and  scope  significantly  in  1996.  During  1997,  Architectures  Working  Group 
(AWG)  conducted  the  third  phase,  proof  of  concept.  In  1999,  the  pilot  assessments  were 
conducted  and  the  Initial  Operational  Capability  (IOC)  2000  followed.  A  snapshot  of  the 
evolution  is  summarized  in  figure  2-1  below.  (DOI,  2000) 


Ligure  2-1.  Evolution  of  LISI,  from  (DOI,  2000) 
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1.  Exploratory  Phase,  Intelligence  Systems  Council  (ISC),  1994  (Birth  of 
the  Concept) 

In  1993,  the  ISC  was  at  the  end  of  its  wits.  U.S.  military  force  deployments 
continued  to  indicate  that  the  automated  information  systems  used  by  the  military 
departments  did  not  interoperate  well,  if  at  all.  Individual  organizations  and  program 
managers  had  their  own  interpretations  of  “interoperability.”  When  consensus  could  not 
be  reached,  the  member  organizations  turned  to  the  formal  definition.  According  to  the 
Joint  Publication  1-02,  DOD  Dictionary  of  Military  and  Related  Terms,  interoperability 
is  defined  as  follows: 

The  condition  achieved  among  communications- electronic  systems  or 
items  of  communications -electronic  equipment  when  information  and 
services  can  be  exchanged  directly  and  satisfactorily  between  them 
and/or  their  users.  The  degree  of  interoperability  should  be  defined 
when  referring  to  specific  cases.  (DOI,  2000) 

The  ISC  participants  focused  heavily  on  the  last  sentence  in  the  DOD  definition, 
and  recognized  the  need  to  define  “degrees”  or  “levels”  of  interoperability  that  could 
accomplish  the  following: 

a.  Serve  to  discriminate  major  variances  in  required  Joint  information  transactions 
and  sophistication  from  one  system  to  another. 

b.  Provide  for  a  simple  construct  to  facilitate  cross-organizational  coordination. 

c.  Enable  interoperability  assessments  of  intelligence  and  Command  and  Control 
(C2)  systems  that  need  to  interact. 

d.  Serve  to  guide  or  discipline  interoperability  improvement  actions.  (DOI,  2000) 

2.  Analysis  Phase,  C4ISR ITF,  1995-1996  (DOD  Endorsement) 

In  October  1995,  the  Deputy  Secretary  of  Defense  tasked  (ASD)  (C3I)  to  define 
and  develop  better  means  and  processes  to  ensure  C4I  capabilities  most  effectively  meet 
the  needs  of  our  warfighters.  In  response  to  this  tasking,  the  C4ISR  ITF  was  established 
and  an  Integrated  Architectures  Panel  (IAP)  was  created  to  engineer  a  C4ISR  architecture 
process  and  identify  ways  to  improve  systems  interoperability.  The  IAP  advocated  the 
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concept  of  “Level  of  Interoperability”  as  mechanism  for  C4ISR  practitioners  to  negotiate 
an  affordable  and  technically  appropriate  capability  mix  among  C4ISR  systems  intended 
to  interoperate,  and  to  ensure  Joint  interoperability.  Finally,  The  Under  Secretary  of 
Defense  Acquisition  and  Technology  (USDA&T),  the  Assistant  Secretary  of  Defense 
(ASD)  (C3I),  and  Vice  Chairman  of  the  Joint  Chiefs  of  Staff  (VCJCS),  endorsed  the 
levels  of  interoperability  concept  and  tasked  the  ASD  (C3I)  to  lead  a  follow-on  effort  to 
“define  and  use  Levels  of  interoperability”  (DOI,  2000) 

3.  Proof  of  Concept  Phase,  C4ISR  AWG,  1997-1998  (Architectural 
Framework  Integration) 

Building  upon  the  recommendations  of  the  C4ISR  ITF  and  the  LISI  report 
published  in  June  1996,  MITRE  Corporation  was  tasked  to  continue  to  work  with  the 
C4ISR  community  to  further  evolve  LIST  In  an  effort  to  engage  DOD  community 
participation,  an  Interoperability  Panel  was  formed  in  January  1997  as  part  of  the  C4ISR 
AWG  sponsored  jointly  by  the  ASD  (C3I)  and  the  Joint  Staff  (JS)  J-6.  (DOI,  2000) 

4.  Application  And  Evaluation  Phase,  DOD,  1999-2000  (Pilot 
Assessments) 

At  the  request  of  the  Army  Systems  Engineering  Office  with  coordination  of  the 
Horizontal  Technology  Integration  Office,  PEO  C3S,  MITRE  undertook  the  pilot 
assessment  of  LISI.  In  November  1999,  MITRE  published  their  pilot  assessment  report 
of  the  LISI  using  components  of  the  ABCS.  This  report  discussed  the  development  and 
use  of  the  LISI  prototype  tool  in  its  application  to  Army  Systems.  Software  development 
questionnaire  building  and  prototype  installation  are  described.  Then  the  prototype’s 
utility  is  discussed  through  its  application  to  the  Army’  ABCS  4.0  component  systems. 
(DOI,  2000) 

5.  Initial  Operational  Capability  (IOC),  DOD,  2000-present  (IOC  2000) 

DOI  hosted  a  kickoff  meeting  and  provided  training  on  the  LISI  tool  in  October 
2000  in  response  to  Lieutenant  General  Peter  M.  Cuviello  and  Lieutenant  General  Paul  J. 
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Kern’s  memorandum  directing  the  mandatory  use  of  LISI.  The  IOC  participation 
includes  Army  Materiel  Command  (AMC)  soldier  &  Biological  Chemical  Command 
(BCC),  AMC  Tank  Automotive  Command  (TACOM),  PEO  Aviation,  PEO  Standard 
Army  Management  Information  System  (STAMIS),  and  PEO  Theater  Missile  (TM). 
(DOI,  2000) 

However,  the  LISI  is  a  living  entity  and  will  be  constantly  evolving.  In  concert 
with  technological  advances  in  information  systems  and  changes  in  the  methods  by  which 
enterprises  employ  information  systems  technology  in  support  of  their  operations,  the 
continuing  evolving  of  the  LISI  is  anticipated. 

E.  THE  ELEMENTS  OF  LISI  CAPABILITIES  MODEL 

In  order  to  evaluate  whether  the  LISI  can  improve  IT  interpretabilities,  the 
understanding  of  the  planned  LISI  Capabilities  Model  is  essential.  A  capabilities  model, 
such  as  that  defined  within  LISI,  is  commonly  described  as  a  set  of  concepts,  entities, 
interfaces,  and  diagrams  that  provides  common  ground  for  understanding  and 
comparisons.  It  does  not  provide  a  specific  system  design  or  prescription  for 
implementation,  but  it  does  define  a  common  set  of  services  and  interfaces  for  building 
specific  designs.  In  a  similar  manner,  the  LISI  Capabilities  Model  does  not  prescribe 
specific  implementation  choices  necessary  to  attain  a  level  of  interoperability.  Instead, 
LISI  draws  heavily  from  commonly  existing  organizational  directives  and  mandates.  In 
the  case  of  DOD,  these  implementation  choices  are  derived  from  related  sources  such  as 
the  Joint  Technical  Architecture  (JTA),  Defense  Information  Infrastructure  (DII) 
Common  Operating  Environment  (COE),  and  Shared  Data  Environment  (SHADE). 
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LISI  Capabilities  Model 

Figure  2-2,  from  (OSD,  2000) 
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1. 


The  “Level”  Concept 


a.  Level  0:  Isolated  (Stand  Alone) 


Figure  2-3.  Level  0:  Isolated  Interoperability  in  a  Manual  Environment, 

from  (C4ISR,  1998) 


Figure  2-3  represents  Level- 0  interoperability.  Level  0  is  described  as 
isolated  interoperability  in  a  manual  environment.  The  key  feature  of  Level  0  is  human 
intervention  to  provide  interoperability  where  systems  are  isolated  from  each  other. 
Level- 0  systems  need  to  exchange  data  or  services,  but  cannot  directly  interoperate.  The 
lack  of  direct,  electronic  connectivity  may  exist  solely  due  to  differing  security  or  access 
-  control  policies,  or  it  may  be  a  lack  of  physical  connection  between  two  systems. 
(C4ISR,  1998) 


b.  Connected  ( Peer  to  Peer ) 


Telnet,  FTP, 
E-mail,  Chatter 


Figure  2-4.  Level  1:  Connected  Interoperability  in  a  Peer-to-Peer  Environment, 

from  (C4ISR,  1998) 


Figure  2-4  represents  LISI  Level- 1  interoperability.  Level  1  is  described 
as  connected  interoperability  in  a  peer-to-peer  environment.  The  key  feature  of  Level  1 
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is  physical  connectivity  providing  direct  interaction  between  systems.  Level  1  systems 
have  an  established  electronic  link  characterized  by  separate  peer-to-peer  connections. 
At  this  level  of  interoperability,  the  interactions  are  between  discrete  systems.  Links  can 
locally  support  simple  file  exchanges  between  systems.  The  type  of  files  exchanged  is 
typically  homogeneous  in  context  (e.g.,  text-only  file,  a  bitmap  file).  (C4ISR,  1998) 


Distributed  (Functional) 


c. 


Figure  2-5.  Level  2:  Functional  Interoperability  in  Distributed  Environment,  from 

(C4ISR,  1998) 


Figure  2-5  represents  Level- 2  interoperability.  Level  2  is  described  as 


functional  interoperability  in  a  distributed  environment.  The  key  feature  of  Level  2  is  the 
ability  of  independent  applications  to  exchange  and  use  independent  data  components  in 
a  direct  or  distributed  manner  among  systems.  Level-2  systems  must  be  able  to  exchange 
and  process  complex  (i.e.,  heterogeneous)  files.  These  files  consist  of  items  such  as 
annotated  images,  maps  with  overlays,  and  multi- media  or  hyper- linked  documents.  The 
systems  are  generally  connected  to  multiple  systems  on  local  networks.  A  key  capability 
provided  by  systems  or  applications,  at  the  top  end  of  this  level,  is  the  ability  to  enable 
and  provide  web-based  access  to  data.  (C4ISR,  1998) 
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d.  Integrated  (Domain) 


Figure  2-6.  Level  3:  Domain  Interoperability  in  an  Integrated  Environment,  from 

(C4ISR,  1998) 


Figure  2-6  represents  Level- 3  interoperability.  Level  3  is  described  as 
domain  interoperability  in  an  integrated  environment.  The  key  feature  of  Level  3  is  a 
domain  perspective  that  includes  domain  data  models  and  procedures  where  data  is 
shared  among  the  independent  applications  that  may  begin  to  work  together  in  an 
integrated  fashion.  Level  3  is  characterized  by  multiple  application- to- application 
interactions.  Systems  and  applications  are  interconnected,  but  generally  operate  on  a 
single  functional  set  of  data  (e.g.,  intelligence,  C2,  logistics).  Implementation  at  this 
level  usually  has  only  a  localized  view  of  the  distributed  information  space  and  cross  only 
one  operational  or  functional  domain.  (C4ISR,  1998) 
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e. 


Networked  (Enterprise) 


Figure  2-7.  Level  4:  Enterprise  Interoperability  in  a  Universal  Environment,  from 

(C4ISR,  1998) 

Figure  2-7  presents  Level  4  interoperability.  Level  4  interoperability  is 
described  as  enterprise  interoperability  in  a  universal  environment.  The  key  feature  of 
Level  4  is  a  top-level  perspective  that  includes  enterprise  data  models  and  procedures, 
where  data  is  seamlessly  shared  among  the  applications  that  work  together  across 
domains  in  a  universal  access  environment.  Level  4  is  the  ultimate  goal  of  information 
systems  seeking  interoperability  across  functional  activities  and  informational  domains 
(e.g.,  Intelligence,  C2,  and  Logistics).  At  this  enterprise  level,  information  is  shared 
globally  through  distributed  information  architecture.  Applications  and  systems  operate 
as  necessary  across  all  the  functional  data  domains.  The  ‘virtual’  workspace  uses  shared 
applications  operating  against  an  integrated  information  space.  Level  4  represents  the 
capabilities  necessary  to  achieve  concepts  proposed  in  DOD’s  Joint  Vision  2010 
documents.  (C4ISR,  1998) 

2.  The  “Attributes”  -  PAID 

LISI  categorizes  the  various  aspects  of  information  systems  interoperability  in 
terms  of  four  comprehensive,  closely  interrelated  attributes:  Procedures,  Applications, 
Infrastructure,  and  Data  (PAID).  They  are  the  enablers  of  interoperability  and  its 
various  maturity  levels.  Individually,  these  attributes  are  like  pieces  of  a  puzzle,  each 
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possessing  its  own  identity  (shape)  and  purpose  (content).  When  joined  together 
(pictured  in  Figure  2-8),  these  attributes  can  be  represented  as  a  complete  circle  whose 
“circumference”  encompasses  the  entire  realm  of  interoperability  issues  and 
considerations  and  whose  “area’  defines  the  full  set  of  conditions,  characteristics,  and 
criteria  necessary  for  achieving  interoperable  environments.  Consideration  and 
understanding  of  the  interrelationships  between  all  the  PAID  attributes  are  critical  for 
moving  interoperability  beyond  the  simple  connection  between  systems.  In  order  to 
assess  interoperability  completely,  it  is  necessary  to  apply  PAID  throughout  each  of  the 
levels  described  in  section  2.5.1. 


\\  hat  policies  and 
procedures  enable 
systems  to  exchange 
information, 
capabilities,  and 
services? 


What  set  of 
applications  enable 
information 
exchange,  processing, 
or  manipulation? 


Procedures 


Applications 


V\  hat  information 
formats,  data 
protocols,  or 
databases  enable  the 
exchange  of  data  and 
information? 


What  environment 
(hardware, 
communications  and 
networks,  system 
sen  ices,  and 
security)  enables 
system  interaction? 


Figure  2-8.  The  PAID  Attributes,  from  (Levine,  2000) 


a.  Procedures 

It  encompasses  the  many  forms  of  documented  guidance  and  operational 

controls  that  affect  all  aspects  of  system  development,  integration,  and  operational 

functionality.  This  attribute  addresses  specific  implementation  options  selected  for  a 

system  or  systems  as  well  as  overarching  standards  and  architecture  guidance  for  the 

given  enterprise.  It  encompasses  operational  and  functional  program  development 

guidance  as  well  as  technical  and  system  architecture  standards  (such  as  hardware, 

system  software,  communications  data,  and  applications).  Items  that  make  up  the 
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procedures  attribute  are  organized  into  four  major  categories  that  span  the  levels  of 
interoperability 

a.  Standards:  Technical  Standards,  Technical  Architectures,  and  Common 

Operating  Environment  (COE) 

b.  Management:  Mission,  Doctrine,  Systems  Requirement  Definitions, 

Installation,  and  Training 

c.  Security  Policy:  Classified,  Unclassified,  or  Secret 

d.  Operations:  Network,  E-Mail  Servicing,  and  Bandwidth  Considerations 

(C4ISR,  1998) 

b.  Applications 

It  encompasses  the  fundamental  purpose  and  function  for  which  any 
system  is  built,  that  is,  its  mission.  The  functional  requirements  specified  by  users  to 
perform  an  operational  activity  are  the  very  essence  of  the  software  application.  Whether 
it  is  the  need  to  do  simple  word  processing  or  perform  advanced  nuclear  targeting,  the 
functions  being  accomplished  and  the  applications  that  support  them  represent  the 
system’s  capabilities  to  the  user.  For  interoperability  to  occur  effectively,  similar 
capabilities  or  a  common  understanding  of  the  shared  information  must  exist  between 
systems;  otherwise,  users  have  no  common  frame  of  reference.  (C4ISR,  1998) 

c.  Infrastructure 

It  supports  the  establishment  and  use  of  a  “connection”  between  systems 
or  applications.  This  connection  may  be  a  simple,  extremely  low-level  exchange,  or  it 
could  consist  of  wireless  Internet  Protocol  (IP)  networks,  operating  at  multiple  security 
levels.  These  two  examples  point  out  the  breadth  of  the  communications  and  hardware 
aspects.  Infrastructure  also  includes  “system  services”  that  facilitate  systems  operations 
and  interactions.  These  are  items  such  as  communication  protocol  stacks  and  object 
request  brokers  that  are  used  by  functions  to  establish  and  affect  interactions  between 
systems.  The  security  devices  and  technical  capabilities  that  are  used  to  implement 
security  procedures  also  make  up  a  part  of  infrastructure.  (C4ISR,  1998) 
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d.  Data 

It  focuses  on  the  information  processed  by  the  system.  This  attribute  deals 
with  both  the  data  format  (syntax)  and  its  content  or  meaning  (semantics).  It  includes  all 
the  forms  of  data  that  support  every  level  of  a  system’s  operations,  which  is  from  its 
operating  system  and  communications  infrastructure  to  the  full  set  of  end-user 
applications.  The  data  attribute  embodies  the  entire  range  of  information  styles  and 
formats:  free  text,  formatted  text,  databases  (formal  and  informal),  video,  sound, 
imagery,  graphical  (map)  information,  etc.  As  such  the  data  attribute  is  understandably 
the  most  critical  aspect  of  attaining  systems  interoperability.  It  is  within  this  attribute 
where  much  of  today’s  focus  and  work  towards  building  interoperable  systems  is  taking 
place,  such  as  defining  standard  file  formats,  standards  of  databases,  and  data  definitions. 
(C4ISR,  1998) 

F.  LISI  AND  DOD  IT  INITIATIVES 

There  are  numerous  DOD  initiatives  that  are  focused  on  one  or  more  aspects  of 
interoperability.  Each  initiative  lends  an  important  contribution  to  the  process  of 
improving  interoperability.  What  is  lacking  is  a  way  to  pull  all  of  these  together  to  give 
meaning  to  statements  about  interoperability.  LISI  is  the  key  tying  it  all  together,  using  a 
uniform  capability-  model  structure  and  discipline,  and  a  comprehensive  coverage  of  all 
key  aspects  of  the  PAID  attributes  as  discussed  in  section  2.5.2.  LISI  works  to  track 
these  initiatives  and  their  associated  constructs,  interrelate  them  using  the  family  of  LISI 
models,  leverage  their  findings  and  positions  into  the  LISI  assessment  process,  and 
provide  the  integrated  basis  for  coordinating  these  initiatives  to  maintain  consistency  and 
currency.  The  examples  of  how  LISI  integrates  and  interrelates  to  these  DOD  initiatives 
are  summarized  in  the  following.  (C4ISR,  1998) 
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1. 


Joint  Technical  Architecture  (JTA) 
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Figure  2-9  Cross  Mapping  of  JTA  and  LISI,  from  (C4ISR,  1998) 


The  JTA  has  been  explicitly  incorporated  into  the  LISI  process.  Figure  2-9 
presents  an  extract  from  the  detailed  mapping  of  LISI  and  the  JTA.  The  LISI  Capabilities 
Model  includes  the  relevant  standards  from  the  JTA.  Those  PAID  capabilities  and 
implementations  of  each  LISI- assessed  system  or  application  that  comply  with  JTA 
standards  are  identified  as  such  in  the  system’s  Interoperability  Profile.  Each  entry  in  the 
LISI  Options  Tables  that  is  also  in  the  JTA  is  identified  as  such.  Therefore,  LISI  can 
identify  which  implementation  of  any  system  or  application  conforms  to  JTA  standards 
and  which  implementations  are  outside  the  accepted  standards  found  within  the  JTA. 
(C4ISR,  1998) 

2.  Defense  Information  Infrastructure  (DII)  Common  Operating 
Environment  (COE) 

Although  LISI  and  DII  COE  differ  significantly  in  terms  of  purpose  and  scope, 
they  are  complementary  initiatives.  The  DII  COE  focuses  on  the  portability  of  software 
and  the  configuration  management  of  application- to- operating  environment  interactions 
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and  LISI  focuses  on  the  system- to- system  interactions  that  characterize  interoperability. 
However,  twenty  percent  of  the  DII  COE  Integration  and  Runtime  Standards  (I&RTS) 
Compliance  Checklist  questions  map  directly  into  LISI.  These  questions  relate  to  topics 
such  as  infrastructure  implementations,  applications,  security  issues,  and  naming 
conventions.  Figure  2- 10  presents  a  portion  of  the  complete  DII-to-LISI  crosswalk  table 
in  order  to  demonstrate  the  mapping  process.  (C4ISR,  1998) 
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Figure  2-10.  Cross-Mapping  of  DII  COE  and  LISI,  from  (C4ISR,  1998) 

3.  DII  Master  Plan 

The  DII  Master  Plan  is  a  broad  document  meant  to  insure  that  an  infrastructure  is 
in  place  within  the  DOD  to  allow  for  the  establishment  of  a  common  link  between 
systems  as  they  develop.  The  ability  of  systems  to  work  within  the  Information 
Infrastructure  defined  by  this  plan  is  critical  to  ensuring  interoperability.  Therefore, 
initiatives  focused  on  implementation  of  the  DII  Master  Plan  should  be  closely 
coordinated  with  LISI.  In  particular,  the  way  that  LISI  captures  the  various  aspects  of  the 
infrastructure  that  are  included  within  the  scope  of  the  DII  Master  Plan  on  a  “level-by- 
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level”  basis  should  be  closely  synchronized  with  Master  Plan  implementation  planning 
efforts. 

4.  Shared  Data  Environment  (SHADE) 

SHADE  is  representative  of  the  effort  within  the  DOD  C4ISR  community  to 
reach  agreement  on  common  data  models  for  systems.  It  is  a  fairly  recent  initiative,  and 
is  not  currently  as  well  defined  as  the  DII  COE.  The  SHADE  effort  is  critical  to  defining 
those  aspects  of  data  needed  for  interoperability  maturity.  A  preliminary  review  of 
SHADE  was  performed  to  determine  that  the  LISI  process,  especially  the  data  attribute  of 
PAID,  is  consistent  with  SHADE’S  direction.  LISI  does  not  attempt  to  define  data 
models,  but  merely  records  their  usage.  Deliberate  and  continuous  coordination  must  be 
conducted  to  ensure  that  USI  and  SHADE  are  tightly  integrated  as  they  both  evolve. 
(C4ISR,  1998 

5.  Joint  Battle  Center  (JBC) 

Maintaining  the  currency  of  capabilities  and  implementation  captured  by  LISI  is 
critical  as  technical  standards  continue  to  evolve  and  as  commercial  industry  continues  to 
release  new  technologies.  The  LISI  options  tables  that  identify  the  numerous  alternatives 
available  for  implementing  the  general  capabilities  profiled  in  the  LISI  Capabilities 
Model  must  be  continuously  updated.  This  update  process  must  be  performed  in  close 
coordination  with  the  operational  user  community,  industry,  and  the  acquisition 
community.  The  JBC  is  an  organization  where  many  of  these  groups  come  together  to 
examine  system  performance  and  interoperability  in  context  with  Joint  Task  Force  (JTF) 
mission  operations.  The  collective  insight  these  groups  bring  makes  the  JBC  an  ideal 
forum  for  capturing  these  integrated  views  using  the  LISI  construct  and  process.  (C4ISR, 
1998) 


6.  Joint  Interoperability  Test  Command  (JITC) 

The  JITC  is  faced  with  the  daunting  task  of  testing  and  certifying  DOD  information 
systems.  The  sheer  number  of  systems  makes  it  impractical  to  test  every  possible 
system- to- system  combination.  By  looking  at  products  produced  by  LISI,  particularly 
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the  various  system  interoperability  profiles,  critical  interfaces  between  systems  can  be 
identified.  The  LISI  products,  in  conjunction  with  architecture  information  and  JBC 
experimentation  results,  serve  a  ‘screening”  function  in  pinpointing  what  specific  aspects 
of  system  to-system  interoperability  are  most  critical  or  most  at-risk.  These  are  the  areas 
where  testing  of  systems  should  focus,  where  compliance  and  surety  are  most  important, 
and  where  testing  will  yield  a  high  payoff.  The  JITC  could  use  the  results  of  LISI 
assessments  to  build  Test  and  Evaluation  master  Plans  (TEMPs).  These  plans  will  be 
able  to  validate  the  particular  implementations  that  are  most  critical  to  interoperability 
with  other  systems.  (C4ISR,  1998) 

G.  BENEFITS  OF  IMPLEMENTING  LISI 

Before  LISI,  there  was  no  widely  accepted  performance-based  or  results-based 
standard  for  interoperability.  Now  LISI  directly  supports  the  development  of  IT 
architectures  within  the  context  of  ITMRA  by  assessing  the  level  of  interoperability 
required  and  attained  between  systems.  In  addition  to  being  able  to  tie  all  DOD  IT 
initiatives  together,  using  a  uniform  capability- model  structure  and  discipline,  and  a 
comprehensive  coverage  of  all  key  aspects  of  the  PAID  attributes,  several  benefits  of 
implementing  LISI  can  be  identified  as  the  following.  (AWG,  1998) 

1.  Quantify  Interoperability 

LISI  revokes  the  ambiguity  in  determining  levels  of  interoperability.  In  addition 
to  an  overall  rating,  LISI  measures  interoperability  along  each  of  its  four  axes,  PAID,  and 
provides  the  manager  with  a  formal  scorecard  for  interoperability  through  the  common 
reference  model.  The  LISI  model  identifies  the  stages  through  which  systems  should 
logically  progress,  or  “mature’,  in  order  to  improve  their  capabilities  to  interoperate. 

LISI  also  considers  five  increasing  levels  of  sophistication  regarding  system  interaction 
and  the  ability  of  the  system  to  exchange  and  share  information  services.  Each  higher 
level  represents  a  demonstrable  increase  in  capabilities  over  the  previous  level  of  system- 
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to- system  interaction.  By  quantifying  interoperability,  LISI  provides  a  common  DOD 
basis  for  requirements  definition  and  for  incremental  system  improvements. 

2.  Aid  in  Establishment  of  Appropriate  Level  of  Interoperability 

LISI  saves  managers  money.  Not  all  projects  require  the  same  level  of 
interoperability.  By  establishing  a  common  set  of  definitions  and  operating  assumptions 
about  interoperability,  LISI  allows  decision-makers  to  specify  appropriate  levels  of 
interoperability.  A  squad  level  communication  device  has  fewer  requirements  for 
interoperability  than  does  a  national  level  collection  and  processing  center,  but  without 
some  way  of  specifying  an  appropriate  level,  the  manager  is  left  trying  to  guess  and 
he/she  perhaps  overestimates  the  level  of  interoperability. 

3.  Provide  Fully  Integrated  View 

LISI  looks  at  the  entire  program  to  include  policies  and  procedures  for  system 
implementation.  It  is  not  limited  to  the  technical  view. 

4.  Track  Interoperability  Level  Throughout  Life  Cycle 

LISI  helps  programs  throughout  their  lifecycles.  During  the  design  phase,  LISI 
helps  managers  identify  gaps  in  interoperability  between  proposed  and  existing  systems. 
Managers  can  use  the  LISI  “scorecard”  to  track  their  project’s  interoperability  level 
throughout  system  development.  LISI  suggests  economical  fixes  for  interoperability 
gaps. 


5.  Serve  As  Management  Tool 

LISI  will  benefit  all  communities  from  the  Program  Managers  (PMs)  to 
assessment  and  oversight  bodies.  The  LISI  interoperability  assessment  process  provides 
expedient  and  collaborative  mechanisms  and  common  metrics  for  DOD  to  assess  current 
interoperability  postures,  to  identify  quick- fix  options,  to  develop  strategies  for 
achieving  higher  states  of  interoperability  maturity,  and  for  providing  timely  feedback  to 
DOD  standards  bodies. 
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The  joint  mission  planners  can  use  LISI  in  context  with  mission  area  assessments 
to  facilitate  the  development  and  dissemination  of  interoperability  requirements  for  new 
systems.  The  PMs  can  use  LISI  to  identify  potential  interoperability  problems  early  in 
the  analysis  phase  of  system  development  rather  than  discover  issues  after  system 
fielding.  Also,  the  command  architects  can  use  LISI  to  assess  the  interoperability  of 
systems  in  an  existing  or  planned  architecture  and  evaluate  alternative  strategies  to 
improve  interoperability  to  meet  the  mission  and  operational  requirements. 

H.  CHAPTER  SUMMARY 

LISI  is  a  maturity  model  and  interactive  process  for  assessing  and  improving 
interoperability.  It  is  a  discipline,  a  work  ethic,  a  structured  approach,  and  a  measure  of 
performance  for  improving  interoperability  but  it  is  not  a  prescription  for  guaranteeing 
interoperability. 

LISI  was  initiated  in  1993  because  the  military  services  have  a  long  history  of 
interoperability  problems  during  joint  operations.  The  motivations  for  LISI  to  continue 
for  developing,  prototyping,  and  implementing  are  multifaceted.  To  name  a  few,  the 
motivations  are  to  achieve  information  superiority,  to  support  JTF,  to  comply  with 
ITMRA,  to  assist  in  the  certifying  process  and  improving  C4I  systems’  interoperability, 
to  implement  GAO  recommendations,  and  to  become  a  mandatory  interoperability 
assessment  tool. 

The  “Levels”  and  the  “Attributes”  are  the  essential  elements  of  LISI.  LISI 
considers  five  increasing  levels  of  sophistication  with  respect  to  exchanging  and  sharing 
information  and  services.  Each  higher  level  represents  a  demonstrable  increase  in 
capabilities  over  the  previous  level  of  system- to- system  interaction.  This  increase  is 
expressed  in  terms  of  PAID  -  the  Procedures  imposed  by  information  management,  the 
capabilities  of  Applications  that  act  on  that  data,  the  type  of  Infrastructure  required, 
and  the  nature  of  Data  transferred. 

There  are  several  DOD  initiatives  to  improve  information  interoperability,  why 
LISI?  Evidently,  LISI  is  the  key  tying  all  the  initiatives  all  together  using  a  uniform 
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capability-  model  structure  and  discipline,  and  a  comprehensive  coverage  of  all  key 
aspects  of  the  PAID  attributes.  In  addition,  LISI  will  benefit  the  joint  mission  planners, 
the  program  managers,  command  architects,  and  all  information  system  communities  to 
establish  an  appropriate  level  of  interoperability,  to  quantify  interoperability,  to  assess, 
and  to  improve  system  interoperability. 
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in.  HOW  DOES  LISI  PROCESS  WORK? 


A.  INTRODUCTION 

A  web-based  tool,  Inspector  1.0,  has  been  used  to  support  the  interoperability 
assessment  that  the  LISI  system  provides.  As  discussed  in  chapter  II,  LISI  is  a  maturity 
model  and  interactive  process  for  assessing  and  improving  interoperability.  The 
Inspector  has  been  developed  to  provide  such  processes  as  determining  interoperability 
needs,  assessing  the  ability  of  specific  information  systems  to  meet  those  needs,  and 
selecting  pragmatic  solutions  and  transition  paths  for  achieving  higher  states  of  capability 
and  interoperability. 

Inspector  receives  inputs  via  a  system  survey  questionnaire.  The  LISI  survey 
contains  a  questionnaire  that  can  be  completed  through  a  web  interface  to  capture 
relevant  data  about  a  system.  The  tool  then  performs  the  mapping  of  the  capabilities 
against  the  model,  and  calculates  the  resulting  profile  and  level.  Users  register  system 
characteristics  by  selecting  the  appropriate  responses  to  the  questions.  Questionnaire 
responses  are  directly  shared  within  the  database  and  stored  in  a  table  from  which  data 
can  be  used  to  create  a  set  of  products  (outputs).  Hopefully,  the  interoperability 
managers  can  use  the  LISI  reports  to  identify  gaps,  shortfalls,  and  improvement  strategies 
and  agreements  of  system  interoperability. 

The  access  to  the  LISI  Inspector  is  password  controlled  and  the  data  privacy  in  the 
LISI  Inspector  is  highly  protected.  The  first  step  in  registering  a  system  is  to  acquire  a 
user  account  from  the  System  Administrator  (8A).  The  LISI  tool  is  web  based  and  is 
intended  to  be  user  friendly.  It  completed  a  series  of  major  enhancements  during  FY  99 
that  resulted  in  several  incremental  “versions,”  each  representing  a  major  increase  in 
either  software  performance  and  /or  a  significant  expansion/enhancement  of  the  survey 
questionnaire.  Inspector  currently  contains  approximately  220  questions  covering  a  wide 
range  of  topics.  These  questions  now  contain  over  3,000  possible  answers  that  are 
currently  composed  of  over  12,000  individual  response  fields.  (MITRE,  August  2000) 
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How  LISI  works  through  Inspector  will  be  discussed  in  more  detail  throughout 
this  chapter.  A  capsule  view  of  LISI  can  be  depicted  as  the  following,  figure  3-1. 


LISI  Questionnaire 


System  “S2  ” 
Interoperability  Metric 


Forums  for  Investment  Strategies  & 
technology  Insertion 


S2  Interoperability  Matrix 
(The  “ Scorecard ”) 


Figure  3-1.  A  Capsule  View  of  the  LISI  Assessment  Process,  from  (MITRE,  August 
2000) 


B.  LISI  TOOL  -  INSPECTOR  1.0 


Inspector  1.0  is  a  web-based  tool  for  capturing,  manipulating,  and  analyzing 
information  technology  (IT)  system  characteristics  in  context  with  any  x-y  coordinate- 
based  reference  model.  In  addition  to  DII  COE  Runtime  Environment  Compliance 
Levels  and  International  Standard  Organization  -Open  Systems  Interconnection  (ISO- 
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OSI)  Protocol  Stacks,  LISI  Capabilities  Model  is  one  of  the  reference  models  that 
Inspector  1.0  processes. 

Inspector  receives  inputs  via  a  system  survey  questionnaire.  Questionnaire 
responses  are  directly  shared  within  the  database.  As  a  result,  data  being  entered  into  any 
of  the  specific  surveys  (e.g.,  LISI)  is  automatically  entered  into  the  other  surveys  (e.g., 

DII  COE,  OSI).  Inspector  also  provides  the  ability  to  import  and  export  data.  Data 
extracts  are  constructed  as  comma- delimited  text  files  that  can  be  sent  using  most 
standard  email  programs. 

In  order  to  decide  whether  LISI  can  improve  interoperability,  it  is  important  to 
understand  what  its  tool  is  all  about  and  how  the  tool  works.  A  brief  overview  of 
Inspector  1.0  will  be  examined  in  term  of  its  evolution,  functionality,  hardware  and 
software  requirements,  and  access  procedures  as  follows. 

1.  Inspector  1.0  Evolution  -  Software  Enhancements  and  Questionnaire 
Revisions 

Inspector  1.0  includes  five  system  surveys,  1)  LISI  survey,  2)  DII  COE 
Integration  and  Runtime  Standards  (I&RTS)  version  3.1  Survey,  3)  DII  COE  I&RTS 
version  4.0  Survey,  4)  Open  Systems  Interconnection  (OSI)  Survey,  and  5)  US  Message 
Text  Format  (USMTF)  Functional  Survey.  Each  survey  has  its  own  structure  and 
question  set.  Both  Versions  3.1  and  4.0  DIICOE  Surveys  cover  the  12-to-13  functional 
areas  identified  in  I&RTS  versions.  The  OSI  Survey  contains  a  structure  based  on  the 
OSI  Reference  Model  (including  major  protocol  suites).  The  USMTF  Functional  Survey 
covers  each  USMTF  functional  area.  The  LISI  Survey  focuses  on  the  four 
interoperability  attributes:  Procedures,  Applications,  Infrastructure ,  and  Data. 

Inspector’s  evolution  from  a  prototype  to  an  operational  capability  has  been 
driven  primarily  by  expansion  of  the  LISI  Survey.  The  DII  COE  and  the  OSI  Survey  are 
both  relatively  new  items.  The  USMTF  Survey  is  a  restructuring  of  USMTF  messages 
by  functional  area  (they  are  listed  in  the  LISI  Survey  by  USMTF  message  number).  In 
all  cases  where  a  response  option  is  common  to  questions  in  multiple  surveys,  when  that 
response  is  checked  in  one  survey,  it  will  automatically  be  checked  in  all  other  applicable 
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surveys.  The  OSI,  USMTF,  and  some  of  the  DII  COE  Surveys  contain  questions  with 
response  options  in  common  with  each  other  and  with  the  LISI  Survey.  (MITRE,  August 
2000) 


2.  Inspector  1.0  Functional  Components 

Inspector  provides  functionality  in  several  key  areas,  including  database 
management,  user  input  of  system  data,  customization  and  use  of  the  survey 
questionnaire,  and  output  and  presentation  of  reports  for  comparative  analysis  of  the 
system  data.  Inspector  provides  a  database  management  environment  to  manage 
information  concerning  both  the  systems  being  evaluated  and  the  information  contained 
within  the  questionnaires  and  their  relationships  to  the  x-  y  coordinate-based  reference 
models,  such  as  LISI  Reference  Model.  The  system  information  includes  administrative 
data  such  as  system  name,  organization,  point  of  contact,  and  version.  It  also  includes  a 
compilation  of  the  interoperability  characteristics  of  each  system  as  captured  through  use 
of  the  system  surveys.  (MITRE,  August  2000)  The  Inspector’s  major  functional 
components  are: 


a.  Survey  Questionnaire 

It  is  the  survey  interface  portion  of  Inspector  that  allows  users  to  input 
information  describing  their  systems  through  a  questionnaire. 

b.  Multiple  Survey  Capability 

The  data  calls  can  exploit  the  existing  data  since  Inspector  is  configured  to 
provide  credit  for  a  single  answer  across  all  appropriate  questionnaires. 

c.  Reports 

Inspector  generates  reports  that  reflect  the  information  describing  the 

systems. 
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d.  Questions  Builder 

Inspector  currently  provides  a  means  for  creating  new  questions  through 
the  use  of  an  administrative  tool  built  to  operate  within  a  standard  web-browser. 

e.  Data  Exchange 

With  the  delivery  of  Inspector  1.0,  organizations  are  able  to  import  and 
export  system  data  using  a  common  process.  If  this  integration  is  accomplished,  the 
information  about  IT  systems  can  then  be  easily  transported  between  Services  and 
Agencies  using  standard  Inspector  database  extracts. 

3.  Inspector  1.0  Hardware  and  Software  Configurations 

Certain  hardware  and  software  configurations  are  required  for  installation  and 
operational  use  of  Inspector.  According  to  MITRE  Corporation,  in  its  Inspector  Version 
1.0  Description  of  August  2000,  the  following  components  and  services  must  be  installed 
before  Inspector  can  operate  correctly: 

a.  Hardware 

Although  Inspector  can  be  successfully  operated  on  less  capable  hardware 
system  configurations,  the  software  demands  of  Windows  NT/Server  and  the  Cold  Fusion 
Server  are  likely  to  result  in  unsatisfactory  performance.  The  recommended  hardware 
configuration  is: 

•  400  MHz  Pentium  Processor 

•  256  Mbs  RAM  (512  Mbs  recommended) 

•  500  Mbs+  free  space 

•  CD-ROM  or  ZIP  drive  available  to  the  server 

b.  Software 

Presently,  Inspector  has  been  verified  and  configured  for  Beta  testing  on 
only  one  operating  system.  The  Inspector  software  was  written  in  a  4GL  that  is  already 
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compatible  with  many  other  Unix  environments  but  verification  testing  has  not  been 
conducted.  The  current  validated  operating  systems  are  Windows  NT  Workstation  or 
Server  4.0  Service  Pack  4  or  higher. 

Some  commercial  software  packages  are  needed  in  order  for  the  Inspector 
software  to  function  such  as  Cold  Fusion  4.0  Server  (Allaire  Corp, 
http://www.allaire.com)  and  a  Web  Server  compatible  with  Cold  Fusion  (Microsoft  IIS 
4.0  or  Peer  Server  and  Personal  Web  Server,  Netscape  Enterprise  and  FastTrack  Servers, 
Apache).  The  minimum  versions  of  useable  web  browsers  that  are  verified  to  work 
properly  with  Inspector  are  Netscape  4.0+  or  Microsoft  Internet  Explorer  4.0+.  However, 
the  Netscape  4.0+  is  the  more  reliable  browser  since  Microsoft  Internet  Explorer  4.01+ 
has  known  problems  such  as  timeout  errors  during  report  generation. 

One  of  the  capabilities  provided  within  Inspector  is  an  ability  to  produce 
an  extract  and  perform  an  automated  update  of  architecture  diagrams  for  import  and  use 
in  NetViz  (soon  to  Aperture,  an  optional  commercial  software  package  that  have  been 
certified).  These  products  are  only  available  at  present  for  Microsoft  Windows-95+ 
configured  machines.  Currently,  individual  workstation  licenses  are  required  for 
operating  these  applications. 

4.  Inspector  1.0  Access  Procedures 

The  following  are  the  steps  for  accessing  Inspector  1.0  to  review  and  enter  system 

data: 

Step  1.  Access  the  web  site:  http://sysarch.army.mil/LISEInspector. 

Step  2.  Enter  system’s  user- id,  its  password,  and  its  domain  name.  The  System 
Administrator  (SA)  authorizes  the  password. 

Step  3.  Highlight  the  desired  survey  in  the  choice  box,  then  press  the  “Select  Survey” 
button  on  the  bottom  of  the  page. 

Step  4.  To  review  &  update  a  system  survey,  “click”  on  the  “Update”  text. 

Step  5.  No  special  action  is  required  on  the  “Inspector  Search  page”  simply  press  the 
“Search”  button  at  the  bottom. 
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Step  6.  Use  the  mouse  to  “click”  on  the  specific  system  you  are  authorized  to  edit.  Use 
the  scroll  bar  on  the  right  to  pan  down.  Once  a  system  has  been  selected,  press  the 
“Access  Data”  button  at  the  bottom  of  the  page. 

Step  7.  The  REGISTRATION  DATA  page  for  the  system  should  now  be  showing.  The 
frame  on  the  left  side  of  the  browser  holds  a  set  of  buttons  used  to  access  various  portions 
of  the  data  contained  within  a  survey.  Update  the  registration  page  and  use  the  “Submit” 
button  at  the  bottom  of  the  page.  If  the  Submit  button  is  not  showing,  you  do  not  have 
the  proper  access  to  edit  this  system  and  you  need  to  contact  the  system  administrator  to 
report  the  problem. 

Step  8.  Inspector  now  presents  the  top-level  questions  for  the  survey  selected  by  the  user. 
Answer  each  question  by  “clicking”  the  appropriate  item  and/or  making  text  entries. 

After  reviewing  and  modifying  as  necessary  any  check-boxes  or  typed  in  text,  press  the 
“Submit  Question  Data”  button  at  the  bottom.  A  “next”  group  of  questions  that  are 
driven  by  the  first  responses  will  automatically  be  presented  each  time  the  “submit” 
button  is  pressed  if  more  questions  apply.  When  the  last  questions  within  the  survey  have 
been  answered,  a  ‘Thank  you”  page  will  show  on  the  right  frame.  The  left  frame  of  each 
survey  page  provides  buttons  that  allow  the  user  to  access  specific  “Categories”  of 
question. 

Step  9.  Repeat  step  8  for  all  applicable  question  sets,  one  at  a  time,  until  the  “thank” 
page  for  each  appears. 

Step  10.  Send  an  email  to  SA  when  the  data  review  and  update  have  been  completed. 

C.  LISI  INPUT 

1.  LISI  Data  Collection 

Inspector  receives  inputs  via  a  system  survey  questionnaire  that  forms  the  bridge 
between  the  LISI  assessment  basis  and  the  LISI  assessment  process  and  products.  LISI 
uses  the  Interoperability  Questionnaire  to  collect  the  pertinent  information  required  to 
assess  information  systems  interoperability.  Because  the  questionnaire  is  linked  to  the 
LISI  models  and  tables  that  comprise  the  assessment  basis,  the  questionnaire  covers  all  of 
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the  different  implementation  choices  and  characteristics  currently  defined  in  the  Options 
Tables  for  the  capabilities  described  within  the  LISI  Capabilities  Model.  (C4ISR,  1998) 

Users  register  system  characteristics  by  selecting  the  appropriate  responses  to  the 
questions.  Answers  are  stored  in  a  table  from  which  data  can  be  used  to  create  a  set  of 
reports.  Questionnaire  data  is  maintained  in  a  “meta-data”  format  eliminating  the  need 
for  additional  software  development  to  extend  the  data  collection  range,  function,  or 
purpose  of  a  questionnaire.  According  to  MITRE  in  its  Inspector  version  1.0  Description 
of  August  2000,  “New  questions  can  be  added  at-will  whenever  the  user  determines  that 
additional  detail  is  needed.”  However,  at  present  time,  the  user  will  have  to  submit  the 
request  for  addition  to  the  SA  if  there  is  any  need. 

2.  Information  Shared  Among  Surveys 

Inspector  currently  provides  the  ability  to  utilize  multiple  questionnaires  relating 
to  almost  any  aspect  of  information  technology  systems.  Inspector  provides  this 
capability  by  using  a  common  “front-end”  for  questionnaire-formatted  data  that  is 
facilitated  through  a  simple,  web-based,  survey  presentation  and  data  collection  module. 
Information  can  then  be  structured  between  surveys  so  that  it  is  directly  shared  within  the 
database.  As  a  result,  data  being  entered  into  the  LISI  questionnaire  is  also  automatically 
entered  into  the  other  surveys  as  appropriate.  For  example,  by  “marking”  the  presence  of 
Transmission  Control  Protocol  (TCP)/Internet  Protocol  (IP)  in  the  LISI  Survey,  it  is  also 
entered  into  the  DII  COE  Runtime  Compliance  Assessment  Questionnaire  (a  COE  Level 
-  1  requirement)  and  is  likewise  properly  registered  as  a  Layer-4  protocol  in  the  OSI 
Reference  Model.  Similarly,  information  about  a  particular  USMTF  message  format 
entered  into  the  LISI  survey  is  also  entered  into  the  USMTF  Configuration  Control  Board 
(CCB)  Functional  Analysis  Survey  and  the  Mission  Needs  Statement  (MNS) 
Requirements  Profiler.  (MITRE,  August  2000) 
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3.  Expansion  of  Questionnaires 

There  is  no  limit  to  the  level  of  detail  that  can  be  entered  into  a  survey 
questionnaire.  Inspector  currently  contains  approximately  220  questions  covering  a  wide 
range  of  topics.  These  questions  now  contain  over  3,000  possible  answers  that  are 
currently  composed  of  over  12,000  individual  response  fields.  During  the  Systems  of 
Systems  Interoperability  Evaluation  meeting  in  October  2000,  Bruce  Thompson,  LISI 
Manager  from  MITRE,  indicated  that  Inspector  started  with  only  twenty- five  questions  in 
the  very  beginning.  When  a  hard  copy  was  requested  in  April  2001  to  show  attributes 
with  “all  questions,”  a  stunning  571-page  report  was  printed. 

Although  the  LISI  Interoperability  Survey  is  growing  larger  on  the  whole,  any 
one  system  typically  answers  only  a  small  subset  of  these  questions.  The  questionnaire  is 
organized  hierarchically  so  that  only  those  questions  that  relate  to  the  capabilities  being 
registered  for  the  system  need  be  answered.  For  example,  systems  indicating  Link- 16  on 
a  higher- level  question  would  answer  an  additional  eight  questions  that  would  not  be 
shown  to  other  systems  that  do  not  indicate  Link- 16  capability.  Likewise,  there  are  16 
questions  about  USMTF  composed  of  over  400  different  message  formats  which  are 
shown  only  if  “USMTF”  is  asserted  on  a  higher  level  question  involving  what  message 
formats  are  supported  within  the  system.  (MITRE,  August  2000) 

4.  Questions  Related  to  PAID  Attributes 

Current  questions  within  the  LISI  Procedures  attribute  address  the  following 
subject  areas: 

•  What  implementation  or  enterprise  directed  standards  are  being  followed? 

•  What  is  the  system’s  security  profile;  which  specific  security  standards  are 
implemented? 

•  To  what  degree  has  DII  COE  compliance  been  attained,  if  applicable? 

•  What  information  exchange  requirement  agreements  have  been  attained  within 
particular  domains,  within  the  DOD  Enterprise,  across- government  agencies,  and 
within  multi-national  forums? 
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Within  the  Applications  attribute,  questions  are  used  to  evaluate  many  different 
application  selections  including  such  areas  as  word  processing,  briefing  development 
packages,  tabular  spreadsheets,  imagery  display  tools,  map  display  tools,  and  what 
collaboration  capabilities  exist. 

The  two  LISI  attributes  that  presently  contain  the  greatest  amount  of  detail  are 
Infrastructure  and  Data.  The  questions  for  Infrastructure  start  by  identifying  what 
simple  interactions  exist  between  systems  and  progress  through  radio,  networks,  and 
types  of  bands,  local  area  networks,  wide  area  networks,  and  finally  multi-level  secure 
configurations.  The  Data  attribute  covers  the  spectrum  from  proprietary  data  protocols, 
through  advanced  heterogeneous  data  products  to  full  database  model  implementations. 
(MITRE,  August  2000) 

D.  LISI  PROCESS 

1.  Generating  an  Interoperability  Profile 

The  system  information  collected  is  consolidated  and  presented  by  subject  area 
and  is  also  mapped  to  the  LISI  levels.  This  information  is  then  kept  as  the  basis  for 
constructing  interoperability  Profiles  and  performing  LISI  assessments.  The  information 
gathered  must  contain  enough  detail  to  allow  selection  of  options  that  characterize  the 
system,  based  on  the  implementation  choices  available  in  the  LISI  Options  Tables.  The 
details  are  then  overlaid  on  the  LISI  Capabilities  Model  to  form  the  system’s 
Interoperability  Profile.  The  LISI  Capabilities  Model  and  its  supporting  LISI  Options 
Tables  together  constitute  the  “engine”  that  drives  the  LISI  process  and  provide  the  basis 
for  developing  the  LISI  products  (outputs,  will  be  discussed  in  Section  3.5).  Lor  each 
entry  identified  in  the  LISI  Capabilities  Model,  there  is  typically  a  variety  of  means  and 
implementations  possible.  The  LISI  process  does  not  dictate  which  implementation  must 
be  used;  it  captures  what  has  been  selected  or  what  is  being  considered. 

Ligure  3-2  illustrates  the  process  of  generating  a  system’s  Interoperability  Profile. 
The  LISI  Capabilities  Model  is  shown  on  the  left.  Samples  of  the  associated  LISI 
Options  Tables  for  infrastructure  implementations  are  shown  in  the  center  of  the  figure. 
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Figure  3-2  shows  the  infrastructure  portion  of  the  system’s  interoperability  profile.  As 
implied  in  the  figure,  for  any  capability  described  in  the  LISI  capabilities  Model  and 
associated  LISI  Options  Tables,  multiple  implementations  are  possible  (e.g.,  Secret 
Internet  Protocol  Router  Network  (SIPRNET),  Non-Secure  Internet  Protocol  Network 
(NIPRNET)  and  Joint  Warfare  Intelligence  Center  Systems  (JWICS)).  Based  on  the 
answers  to  the  LISI  questions  for  the  system  under  analysis,  the  system’s  characteristics 
are  captured  and  mapped  against  the  options  tables.  In  this  example,  the  system 
represented  by  SI  has  SIPRNET  and  DISN-LES  infrastructure  capabilities  and  then 
these  characteristics  are  captured  in  the  system’s  interoperability  profile.  (C4ISR,  1998) 


Figure  3-2.  Generating  an  Interoperability  Profile,  from  (C4ISR,  1998) 


2.  LISI  Levels  and  Threshold  Rules 

A  capabilities  model  provides  a  means  to  identify  the  distinctions  among  systems. 
It  is  defined  in  terms  of  the  discriminators  that  characterize  the  specific  capabilities 
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within  a  system.  These  discriminators  determine  the  specific  nature  and  level  of 
interoperability  of  a  system.  In  order  to  be  assessed  at  a  certain  level,  systems  must  fulfill 
all  of  the  requirements  identified  within  the  PAID  attributes  up  to  the  level  attained. 
Therefore,  the  LISI  level  attained  by  a  system  is  the  “highest  line”  across  PAID  up  to 
which  all  of  the  requisite  PAID  capabilities  have  been  implemented  and  whose 
implementations  have  been  assessed  as  interoperable.  Furthermore,  for  each  PAID 
attribute,  the  level  attained  within  the  individual  attribute  is  attained  only  when  all 
capabilities  of  the  lower  thresholds  are  represented  within  that  attribute. 

Decisions  about  which  thresholds  within  each  attribute  are  essential  or  can  be 
treated  as  inherited  are  embodied  within  two  basic  rules: 

Threshold  Rule  1 :  Within  the  capabilities  model,  there  are  explicit  and  essential 
capabilities  that  every  system  must  possess.  These  capabilities  act  as  barriers  to  being 
rated  at  a  higher  level  until  they  are  accomplished.  For  example,  if  standards  compliance 
is  defined  by  the  enterprise  to  be  an  essential  characteristic  of  the  procedures  attribute  for 
Level  lc/d,  then  a  system  that  is  not  standards  compliant  cannot  be  rated  higher  than 
Level  lb.  This  condition  applies,  regardless  of  whether  all  the  other  characteristics  of  the 
PAID  attributes  are  otherwise  fully  Level- 2b  compliant,  including  those  capabilities 
higher  up  within  the  procedures  attribute. 

Threshold  Rule  2:  Within  the  capabilities  model,  thresholds  are  considered  as 
being  “credited”  to  the  next  higher  level  if  they  have  not  been  designated  as  an  essential 
and  required  capability  as  defined  in  Rule  1.  For  example,  if  a  system  possesses  the  LAN 
characteristic  for  the  infrastructure  attribute  (Level  2b)  and  the  other  three  PAID 
attributes  also  assess  at  this  level,  then  the  system  does  not  specifically  require  the 
existence  or  implementation  of  each  lower- level  threshold  (e.g.,  removable  media)  within 
the  infrastructure  capability  to  be  assessed  as  Level  2b.  (C4ISR,  1998) 

E.  LISI  OUTPUT 

The  collection  and  process  of  registered  profiles  provide  the  basis  for  conducting 
system  comparisons.  The  results  of  these  comparisons  can  be  displayed  in  a  number  of 
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products  that  are  available  to  describe  single  systems  and  support  comparisons  between 
multiple  systems.  These  products  can  be  based  on  any  of  the  user-defined  x-y 
coordinate-based  reference  models  included  within  the  tool.  LISI  Inspector  leverages  the 
data  captured  in  the  questionnaire  to  generate  the  following  four  primary  sets  of 
assessment  products.  Each  set  differs  in  its  presentation,  its  intended  use,  and  the 
interoperability  aspect  it  considers.  (C4ISR,  1998) 

1.  Interoperability  Profiles 

The  Interoperability  Profiles  map  LISI  Questionnaire  data  (answers)  to  the  LISI 
Capabilities  Model  template.  Thus,  the  profiles  capture  the  implementation  choices  for 
each  PAID  capability  present  in  the  systems  being  assessed  in  a  format  that  facilitates 
system- to- levels  and  system- to- system  comparisons.  Individual  system  metrics  can  be 
generated  from  these  profiles. 

a.  Generic  Interoperability  Profile 

It  maps  a  single  system’s  responses  to  the  questionnaire  directly  to  the 
LISI  Capabilities  Model  template.  The  generic  level  of  interoperability  is  the  highest 
level  at  which  the  full  suite  of  capabilities  is  implemented  in  a  given  system  across  PAID. 

b.  Specific  Interoperability  Profile 

It  shows  only  the  common  or  compatible  implementations  between  the 
two  systems ,  the  basis  for  determining  the  highest  level  of  sophistication  that  the  two 
systems  can  support  in  their  interactions  with  each  other. 

c.  Composite  Interoperability  Profile 

It  shows  the  commonalties  between  a  group  of  systems. 

d.  Target  Interoperability  Profile 

It  represents  a  notional  set  of  system  characteristics  for  use  by  developers 
when  designing  new  systems  or  updating  existing  systems.  This  profile  is  different  than 
the  other  three  interoperability  profiles  in  that  it  represents  a  goal  or  direction  for  types 
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or  classes  of  systems .  It  may  initially  be  constructed  from  the  results  obtained  using  a 
Composite  Interoperability  Profile  for  a  set  of  systems  from  a  particular  domain. 

e.  Variations  of  Interoperability  Profiles 

Variations  can  be  applied  to  any  of  the  above  profiles.  The  profiles 
described  above  can  be  varied  in  different  ways  to  change  the  conditions  under  which  the 
information  about  a  system  or  group  of  systems  is  presented. 

2.  Interoperability  Assessment  Matrices 

These  matrices  interrelate  groups  of  systems  based  on  their  generic,  expected,  and 
specific  interoperability  metrics,  i.e.,  levels.  The  results  are  presented  in  a  “system” 
format  that  enables  each  system  pair  to  be  compared  in  depth.  The  generic  level  of 
interoperability  is  the  highest  level  at  which  the  full  suite  of  capabilities  is  implemented 
in  a  given  system  across  PAID.  The  expected  level  of  interoperability  is  determined  by 
comparing  the  generic  levels  of  any  two  systems.  The  specific  level  of  interoperability  is 
determined  by  comparing  each  system’s  specific  implementation  choices. 

The  “scorecard”  nature  of  this  product  makes  it  highly  useful  to  all  players 
involved  in  systems  development,  acquisition,  testing,  and  oversight,  as  well  as  to  those 
responsible  for  mission  and  crisis  planning  and  execution.  The  following  are  the  three 
types  of  Interoperability  Assessment  Matrices:  (C4ISR,  1998) 

a.  Potential  Interoperability  Matrix 

It  can  be  generated  for  a  group  of  systems  based  on  the  generic 
interoperability  level  of  each  system  and  the  specific  interoperability  level  for  each 
system  pair  within  the  group. 

b.  Evaluated  Interoperability  Matrix 

This  is  a  form  of  the  Potential  Interoperability  Matrix  that  has  been 
validated  via  testing  and  experimentation.  Therefore,  this  matrix  reflects  demonstrated 
levels  of  interoperability  attained  between  systems.  It  is  derived  via  editing  the  Potential 

Interoperability  Matrix  to  reflect  actual  field  posture. 
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c.  Projected  Independence  Matrix 

It  is  developed  in  the  same  manner  as  the  Potential  Interoperability 
Matrix ,  except  that  Projected  Interoperability  Matrices  are  provided  for  phases  in  time, 
each  phase  corresponding  to  a  planned  or  postulated  suite  of  capabilities  and 
implementations. 

3.  Interoperability  Comparison  Tables 

These  tables  present  the  results  of  a  system- to-  system  PAID  implementation 
assessment.  They  provide  a  comparison  of  interoperability  implementation  information 
between  systems  in  terms  of  PAID. 

a.  PAID  Implementation  Comparison  Tables 

They  facilitate  attribute-by- attribute  examination  of  the  specific  PAID 
implementation  choices  between  system  pairs,  and  provide  linkages  to  solution 
alternatives.  These  tables  would  be  used  to  determine  the  Specific  Interoperability  Level 
between  systems  as  well  as  to  examine  the  nature  of  the  gaps  and  solution  options 
available.  Each  table  focuses  on  one  of  the  PAID  attributes. 

b.  Interconnection  Requirements  Table 

It  represents  “data  flow”  direction  between  systems.  When  a  PM  registers 
a  system  using  LISI,  there  is  a  portion  of  the  questionnaire  that  calls  for  the  identification 
of  all  other  systems  involved  in  the  system’s  one-way  or  two-way  information  exchanges. 
When  these  identified  requirements  are  compared  across  systems,  unknown  or 
unexpected  relationships  often  are  exposed.  Therefore,  the  table  serves  to  identify 
conflicts  that  would  require  PM- to- PM  coordination  to  resolve.  (C4ISR,  1998) 

3.5.4  Interoperability  System  Interface  Description-  It  reflects  the  interoperability 
aspects  of  information  technology  architectures.  LISI  currently  supports  a  system 
interface  diagram  that  depicts  the  interoperability  level  of  individual  systems  and  the 
interfaces  between  systems  that  are  involved  in  a  particular  mission  operation  or  that  are 
under  scrutiny. 
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F.  LISI  DATA  PRIVACY  AND  CONTROL  POLICY 


LISI  data  privacy  is  highly  protected  by  design  for  all  systems  registered  in  LISI. 
However,  there  is  an  open  security  issue,  as  this  writing,  regarding  the  classification  level 
the  LISI  database  should  properly  be  set  at  has  not  resolved  yet. 

There  are  several  control  points  that  would  demonstrate  this  high  level  of 
protection  as  depicted  in  Figure  3-3. 


System 

Manager 

Owned 


Figure  3-3.  LISI  Privacy  &  Control  Policy,  from  (Levine,  2000) 


a.  The  LISI  system  data  is  configuration  managed  by  Deputy  Chief  of  Staff  for 
Operations  (DCSOPS)  who  has  the  ownership  rights  and  report  access. 

b.  The  LISI  data  are  input  by  Program  Managers  (PM)  or  System  Managers  (SM). 

c.  The  LISI  data  access  is  web  based  and  certain  software  and  hardware  are  required 
for  installation  and  operational  use  of  Inspector  as  discussed  in  section  3.2.3. 
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d.  Access  to  LISI  System  Data  Repository  is  password  protected.  Each  user 
requires  a  user-ID,  password,  and  domain  name. 

e.  A  System  Administrator  for  each  of  the  Services  controls  the  passwords. 

f.  The  level  of  data  release  for  export  is  controlled  by  the  PM  or  SM  who  can 
decide  his  input  will  either  remain  as  “Private,”  be  released  to  “Local,”  or  be 
reclassified  to  “Global”  when  registering  the  system  based  on  his  data  completion 
level.  (Levine,  2000) 

G.  LISI  INSPECTOR  USER-FRIENDLINESS 

The  LISI  Inspector,  a  web-based  tool,  was  designed  to  provide  C4I  systems  a 
user-friendly  process  for  determining  interoperability  needs.  The  questionnaire 
information  collected  in  the  Inspector  is  presented  in  a  user-  friendly  Hyper  Text  Markup 
Language  (HTML)  format,  and  is  captured  through  an  administrative  HTML  interface. 

The  LISI  Inspector  completed  a  series  of  major  enhancements  during  LY  99  to 
make  the  application  of  LISI  Inspector  more  user-  friendly  and  meaningful.  The 
improvements  during  LY  99  have  occurred  through  the  contributions  of  several  key 
organizations.  The  contributors  include  the  Air  Lorce  Electronic  Systems  Center  (ESC) 
C4ISR  Interoperability  Program  Office  (CIPO),  the  Army  Systems  Electronic 
Engineering  Office  (ASEO),  the  Horizontal  Technology  Integration  Office  (HTIO)  at 
PEO  C3S,  the  Marine  Corps  Systems  Command  (MARCORSYSCOM),  the  Ballistic 
Missile  Defense  Office  (BMDO),  the  Unified  Cryptologic  Architecture  Office  (UCAO), 
and  the  Joint  C4ISR  Battle  Center  (JBC).  Each  contributor  also  leveraged  the  expertise 
of  the  Program  Management  Offices  (PMOs)  and  system  developers  within  their  purview 
to  support  the  LISI  development.  The  mentioned  system  developers  are  referring  to 
PATRIOT,  Airborne  Early  Waming/Ground  Environment  Integration  Segment  (AEGIS), 
the  Theatre  Maritime  Battle  Management  Core  System  (TBMCS),  and  the  Army  Battle 
Command  and  Control  System  (ABCS).  (MITRE,  1999) 

Although  the  questionnaires  currently  contain  over  220  questions  covering  3,000 
possible  answers  with  over  12,000  individual  response  fields,  any  one  system  normally 
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has  to  answer  only  a  small  subset  of  these  questions.  The  questionnaire  is  organized 
hierarchically  so  that  only  those  questions  that  relate  to  the  capabilities  being  registered 
for  the  system  need  to  be  answered.  Also,  because  the  questionnaire  data  is  maintained 
in  a  “meta-data”  format,  new  questions  can  be  added  “at-will,”  whenever  the  user 
determines  that  additional  detail  is  needed.  (MITRE,  August  2000)  However,  this  add¬ 
on  capability  of  “at-will”  is  indirect  at  the  writing  of  this  study,  since  the  user  currently 
can  only  make  a  request  of  any  questionnaire  change  through  the  system  administrator. 

The  three- levels  of  data  information  release  is  another  user-friendly  feature.  The 
data  input  can  remain  at  “Private”  level  before  the  system  manager  or  program  manager 
reviews  and  determines  that  the  data  input  for  the  system  is  accurate  and  complete.  The 
users  can  “Print  Survey  “  to  see  the  input  before  re- classifying  the  information  to  the  next 
level,  “Local  “  or  “Global.”  The  “Print  Survey”  also  gives  the  users  choices  to  print  the 
“whole  survey”  or  “one  attribute”  of  the  four  attributes  to  narrow  down  and  concentrate 
on  selected  review  areas. 

H.  CHAPTER  SUMMARY 

LISI  has  been  applied  through  a  web-based  tool,  Inspector  1.0.  The  Inspector’s 
five  major  functional  components  (Survey  Questionnaire,  Multiple  Survey  Capability, 
Reports,  Questions  Builder,  and  Data  Exchange)  make  it  a  powerful  tool  to  capture, 
manipulate,  analyze,  and  share  data  for  all  of  its  five  system  surveys  currently  available 
(LISI,  DIICOE  I&RTS  v3.1,  DIICOE  I&RTS  v4.0,  OSI,  and  USMTF).  Inspector’s 
evolution  from  a  prototype  to  an  operational  capability  has  been  driven  primarily  by 
expansion  of  the  LISI  Survey. 

The  LISI  Survey  focuses  on  the  four  interoperability  attributes:  Procedures, 
Applications,  Infrastructure,  and  Data.  LISI  uses  the  Interoperability  Questionnaire  to 
collect  the  pertinent  information  required  to  assess  information  systems  interoperability. 
Users  register  system  characteristics  by  selecting  the  appropriate  responses  to  the 
questions  and  then  the  answers  are  stored  in  a  table  from  which  data  can  be  used  to  create 
a  set  of  reports. 
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The  information  collected  from  the  LISI  Survey  is  consolidated  and  presented  by 
subject  area  and  is  mapped  into  the  LISI  levels.  The  details  are  overlaid  on  the  LISI 
Capabilities  Model  to  form  the  system’s  Interoperability  Profile.  The  LISI  Capabilities 
Model  and  its  supporting  LISI  Options  Tables  together  constitute  the  “engine”  that  drives 
the  LISI  process  and  provide  the  basis  for  developing  the  LISI  products.  However,  the 
LISI  process  does  not  dictate  which  implementation  must  be  used;  it  captures  what  has 
been  selected  or  what  is  being  considered. 

LISI  Inspector  leverages  the  data  captured  in  the  questionnaire  to  generate  four 
primary  sets  of  assessment  products:  Interoperability  Profiles ,  Interoperability 
Assessment  Matrices,  Interoperability  Comparison  Tables ,  and  Interoperability  System 
Interface  Description.  Each  set  of  products  differs  in  its  presentation,  the  intended  use, 
and  interoperability  aspect  it  considers  as  discussed  under  section  3.5,  LISI  Outputs. 

The  LISI  system  data  is  configuration  managed  by  DCSOPS  and  its  privacy  is 
considered  highly  protected.  A  user- ID,  password,  and  domain  name  is  required  by 

each  user  each  time  to  access  the  web-based  LISI  Inspector.  Although  the  questionnaires 
contain  over  220  questions  covering  3,000  possible  answers  with  over  12,000  individual 
response  fields,  any  one  system  normally  has  to  answer  only  a  small  subset  of  these 
questions.  Also,  new  questions  can  be  added  through  system  administrator  whenever  the 
user  determines  that  additional  detail  is  needed.  The  data  input  by  the  PM  or  SM  may 
remain  as  a  “Private”  file,  or  be  reclassified  to  either  “Local”  or  “Global”  depending  on 
the  level  of  confidence  the  PM  or  SM  has  on  the  data  provided. 

The  LISI  Inspector,  a  web-based  tool,  was  designed  to  provide  C4I  systems  a 
user-friendly  process  for  determining  interoperability  needs.  It  has  completed  a  series  of 
major  enhancements  (contributed  by  multi- services  organizations)  during  FY99  to  make 
the  application  of  LISI  Inspector  user- friendlier  and  more  meaningful.  Also,  in  October 
2000,  Army  conducted  a  Systems  of  Systems  Interoperability  Evaluation  Meeting  to 
embark  on  a  process  that  will  assist  the  Army  in  establishing  a  framework  for 
sustainment  of  an  interoperability  baseline.  The  continuing  effort  in  enhancing  LISI 
process  and  implementation  to  improve  C4I  system  interoperability  is  anticipated. 


49 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


50 


IV.  CAN  LISI  IMPROVE  THE  C4I  SYSTEMS’ 
INTEROPERABILITY? 

A.  INTRODUCTION 

Can  LISI  improve  the  C4I  systems’  interoperability?  The  answer  is  “yes”  that 
LISI  has  the  potential  to  improve  DOD  C4I  systems’  interoperability  “but”  current  LISI 
tool  has  to  be  refined.  The  concept,  theory,  and  mythology  discussed  in  previous 
chapters,  the  application  and  use  of  the  LISI  process  (will  discussed  in  section  4.2),  and 
the  results  from  two  LISI  assessments  (will  be  discussed  in  the  sections  4.3  and  4.4)  led 
to  the  above  conclusion. 

The  motivation  and  development  of  LISI  was  discussed  in  detail  in  Chapters  I 
and  II.  How  the  LISI  process  works  was  also  explained  in  length  in  Chapter  III.  LISI 
was  initiated  in  1993  and  developed  to  comply  with  requirements  that  were  eventually 
codified  in  the  Information  Technology  Management  Reform  Act  (ITMRA)  of  1996  to 
develop  a  process  and  procedure  for  information  technology  and  to  improve  system 
interoperability.  Some  of  the  motivations  of  initiating  LISI  are  to  help  achieve  the 
“information  superiority”  envisioned  in  Joint  Vision  2010,  to  support  Joint  Task  Force,  to 
comply  with  Information  Technology  Management  Reform  Act,  and  to  assist  the 
certifying  process  and  improving  C4I  systems’  interoperability. 

The  Army  pilot  assessment  conducted  by  MITRE  Corporation  and  reported  in 
November  1999  indicated  that  LISI  process  provides  significant  added  value  toward 
Army  system  Engineering  Office  (ASEO)  and  HTIO’s  efforts  to  improve  Army  Battle 
Command  and  Control  system  (ABCS)  interoperability.  However,  the  second  assessment 
conducted  by  PEO  C3S  HTIO  Interoperability  Group  and  reported  in  September  2001 
pointed  out  that  the  current  tool  has  many  deficiencies  and  needs  to  be  refined  and 
upgraded. 
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B.  APPLICATION  AND  USE  OF  LISI  PROCESS 


This  section  demonstrates  the  application  and  use  of  the  LISI  process  and  the 
potential  interoperability  improvement  capability.  It  explains  how  LISI  can  be  used  to 
improve  interoperability  by  assessing,  identifying,  and  recommending  corrective  actions 
for  major  gaps  and  shortfalls  between  and  among  systems  throughout  different  stages  of 
the  Army  system  life  cycle.  This  section  also  discusses  how  LISI  can  be  used  in  different 
phases  of  Army  system  life  cycle.  The  collective  work  performed  across  all  of  these 
efforts  can  significantly  enhance  the  interoperability  maturity  for  Army  C4I  systems. 

1.  To  Develop  Interoperability  Requirements 

LISI  can  support  “requirements”  development  and  analysis  for  a  new  program 
through  the  development  of  a  Target  Interoperability  Profile  (see  section  3.5. 1.4). 

Current  interoperability  profiles  of  existing  systems  that  support  a  particular  function  can 
be  evaluated  using  the  composite  Potential  Interoperability  Matrix  (see  section  3.5.2. 1). 
This  matrix  shows  the  interoperability  levels  between  systems  already  supporting  that 
function.  Using  this  matrix,  a  Target  Interoperability  Profile  for  a  given  system  can  then 
be  created  that  will  leverage  the  implementation  choices  made  by  other  systems  that  have 
the  same  functional  needs  and  relationships.  The  process  of  generating  a  Target 
Interoperability  Profile  for  a  new  system  is  shown  in  Figure  4- 1  below. 
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Figure  4-1.  Establishing  Target  Interoperability  Profiles,  from  (C4ISR,  1998) 


Step  1  :  To  retrieve  profile  information  for  existing  systems  that  performs  a  particular 
function. 

Step  2  :  To  build  the  Potential  Interoperability  Matrix  for  the  systems  that  has  been 
retrieved.  This  matrix  represents  the  potential  for  each  system  to  interoperate  with  the 
others,  and  displays  the  level  at  which  the  interactions  will  potentially  take  place.  This 
matrix  shows  the  interoperability  maturity  of  the  systems  supporting  the  selected 
function.  Gaps  and  shortfalls  are  shown  and  can  be  targeted  for  improvement. 

Step  3  :  To  combine  the  profile  information  for  all  the  systems  retrieved  into  a  Composite 
Interoperability  Profile.  This  product  will  show  what  all  the  systems  supporting  this 
function  have  in  common.  This  profile  can  also  be  added  to  the  previously  generated 
Potential  Interoperability  Matrix  to  show  how  such  a  “composite”  system  relates  to  the 
existing  systems.  Additions  and  changes  can  be  made  to  this  profile  based  on  improving 
interoperability  with  existing  systems  and  incorporating  future  technology  directions. 
Varying  the  capabilities  represented  in  the  Composite  Interoperability  Profile  can 
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perform  risk  analysis  and  cost/benefit  tradeoffs.  The  impact  of  these  changes  can  be 
viewed  in  the  Potential  Interoperability  Matrix  and  an  iterative  process  used  to  arrive  at 
the  desired  “composite”  result. 

Step  4  :  To  publish  the  results  of  the  analysis  as  a  Target  Interoperability  Profile.  This 
product  provides  guidance  to  PMs  and  system  developers  and  serves  as  a  benchmark  for 
systems  that  will  support  this  particular  function.  Thus,  as  the  capabilities  of  new 
systems  are  developed  to  support  the  function,  they  are  built  toward  a  target  that  already 
includes  interoperability  and  interfaces  to  existing  systems.  On  the  other  hand,  where  the 
Potential  Interoperability  Matrix  shows  gaps  or  system to-system  interoperability  issues 
that  preclude  the  clear  derivation  of  “consensus -based”  choices,  the  PMs  of  the  systems 
in  question  would  be  engaged  collaboratively  to  reach  an  agreed-upon  strategy  for 
resolving  the  implementation  differences.  Thus,  a  two-way  benefit  is  realizable.  This  set 
of  capabilities  in  the  Target  Interoperability  Profile  can  be  included  as  a  supplemental  in 
requirements  documents  and  specifications  for  the  new  system.  In  the  DOD,  these 
documents  include  a  Mission  Needs  Statement  (MNS)  and  an  Operational  Requirement 
Document  (ORD). 

A  major  benefit  of  using  LISI  in  this  manner  is  that  interoperability  requirements 
and  specifications  for  the  given  system  would  be  based  heavily  on  the  popular  or 
common  implementations  of  the  PAID  capabilities  that  are  inherent  in  other  systems 
involved  in  similar  Joint  information  exchanges.  This  accessible  ‘view”  into  the  profiles 
and  implementations  of  other  systems  underlies  a  fundamental  value  of  LISI  in  achieving 
interoperability  “convergence’  across  DOD  over  time. 

The  following  are  some  representative  types  of  questions  that  LISI  helps  to 
answer: 

•  What  other  systems  may  need  to  interoperate  with  System  X? 

•  What  are  the  specific  interoperability  characteristics  of  these  systems? 

•  Projecting  a  System-X  profile,  what  does  the  Potential  Interoperability  Matrix 
reveal  (any  gaps  or  shortfalls)? 

•  What  strategy  will  the  systems  agree  to  for  eliminating  interoperability  gaps? 
(C4ISR,  1998) 
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2.  To  Improve  Interoperability  of  An  Existing  System 

One  purpose  of  the  program  management  process  is  to  identify  areas  for 
improvements  in  existing  systems  and  to  transition  to  more  mature  states  or  higher  levels 
of  interoperability  over  time.  LISI  can  identify  interoperability  shortfalls  of  an  existing 
system  as  well  as  show  how  changes  to  that  system  will  improve  its  interoperability. 

After  entering  the  information  about  a  system  into  LISI,  a  PM  can  then  select  and  retrieve 
data  about  other  existing  and  planned  systems  for  comparison.  This  cross-systems 
examination  allows  PMs  to  find  potential  gaps  and  shortfalls  in  their  own  programs  as 
well  as  the  impacts  to  the  other  programs 

For  example,  a  PM  of  one  system  may  have  made  a  particular  PAID 
implementation  choice  that  impaired  the  interoperability  of  that  system  with  two  other 
systems.  By  using  LISI,  the  PM  can  identify  the  potential  problem  and  rectify  the 
condition  in  the  analysis  phase  of  development  rather  than  discovering  the  issue  after 
fielding. 
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Figure  4-2.  LISI  Use  by  PM  of  an  Existing  System,  from  (C4ISR,  1998) 
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How  LISI  can  be  used  by  the  PM  of  an  existing  system  to  improve 
interoperability  is  depicted  in  Figure  4-2  above. 

Step  1  :  To  enter  data  about  the  system.  This  data  goes  into  a  central  LISI  repository 
where  other  system  PMs  will  have  access  to  it  for  doing  comparisons. 

Step  2  :  To  retrieve  LISI  data  about  other  relevant  systems.  The  PM  performs  this  task 
by  selecting  the  appropriate  systems  from  the  database. 

Step  3  :  To  construct  a  Potential  Interoperability  Matrix  based  on  profiles  for  selected 
systems. 

Step  4:  To  compare  the  systems  and  to  detect  potential  interoperability  gaps  and 
shortfalls  that  appear  between  the  systems. 

For  each  potential  problem  between  two  systems,  the  PM  can  examine  the 
implementations  to  determine  if  the  problem  can  be  remedied  by  changing  an 
implementation  selection.  The  PM  can  then  change  LISI  data  to  perform  a  what- if 
analysis.  The  PM  can  then  examine  the  risk  and  cost-effectiveness  of  making  the 
changes  required. 

Some  of  the  questions  that  LISI  can  help  to  answer  are: 

•  What  is  the  specific  LISI  potential  level  of  interoperability  of  System  X? 

•  What  specific  interoperability  issues  exist  between  System  X  and  other  systems 
already  in  place  or  planned? 

•  What  is  required  to  raise  System  X  to  a  higher  level  of  interoperability?  (C4ISR, 
1998) 


3.  Use  of  LISI  as  an  Interoperability  Tool  for  Command  Architects 

The  command  architect  can  retrieve  LISI  data  for  systems  that  comprise  an 
existing  or  planned  architecture.  After  using  LISI  to  perform  an  assessment  of  those 
systems,  the  architect  can  build  LISI  overlays  to  architecture  products,  e.g.,  the  Systems 
Interface  Description  (LISI  Overlay,  see  section  3.5.4).  The  architect  can  then  evaluate 
alternative  strategies  to  improve  interoperability  to  meet  the  mission  and  operational 
requirements  of  concern.  Figure  4-3  below  illustrates  the  process: 
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Figure  4-3.  LISI  Use  by  a  Command  Architect,  from  (C4ISR,  1998) 


Stepl :  The  command  architect  determines  which  systems  are  used  in  the  architecture 
under  analysis. 

Step  2:  The  architect  retrieves  LISI  information  for  those  systems  from  the  LISI 
database  and  then  builds  a  Potential  Interoperability  Matrix  to  evaluate  the  systems. 

Step  3 :  The  command  architect  builds  a  System  Interface  Description  (LISI  Overlay) 
corresponding  to  the  operational  architecture  view  under  evaluation.  Figure  4-3  clearly 
depicts  the  interoperability  levels  of  each  relevant  system  and  the  connecting  interfaces  in 
context  with  the  operational  requirement,  if  known.  Using  notations  and  colors,  this 
diagram  highlights  shortfalls  where  the  achievable  interoperability  is  not  sufficient  to 
support  the  mission  needs.  Where  mission  needs  are  not  clearly  defined,  the  diagram 
depicts  discrepancies  between  the  systems’  assessed  generic,  expected,  and  specific 
levels  of  interoperability  (see  section  3.5.2  for  definitions). 
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Step  4  :  The  command  architect  can  use  LISI  to  identify  interoperability  shortfalls 
graphically.  The  command  architect  can  evaluate  alternatives  by  modifying  the 
information  on  the  systems  involved  and  re-running  the  analysis. 

Given  a  new  system  to  integrate  into  an  existing  architecture,  LISI  can  help  the 
command  architect  answer  the  following  types  of  questions: 

•  What  is  the  assessed  LISI  level  for  the  new  system? 

•  Which  systems  within  the  existing  architecture  is  this  system  potentially  capable 
of  interoperating  immediately? 

•  If  known,  with  which  system(s)  does  this  system  need  to  interoperate?  (C4ISR, 
1998) 

4.  Use  of  LISI  for  Interoperability  “On  the  Fly” 

LISI  can  be  used  to  assess  interoperability  of  existing  systems,  as  they  are  being 
planned  and  combined  for  operational  use.  For  example,  the  DOD  Joint  Task  Forces 
(JTF)  does  not  exist  until  the  need  arises.  When  a  crisis  appears  imminent,  a  variety  of 
systems  are  brought  together  by  the  Services  and  Agenc  ies  who  will  be  participating  in 
the  mission.  These  systems  may  or  may  not  interoperate;  the  new  crisis  could  dictate 
system- to- system  relationships  that  have  not  been  conceived  of  before.  When  the  JTF 
has  a  short  lead  time,  the  problems  associated  with  getting  disparate  systems  to 
interoperate  may  force  the  Commander  of  the  JTF  to  get  by  without  critical  information 
that  otherwise  would  be  accessible  and  transferable  if  the  supporting  systems  interoperate 
at  the  requisite  levels.  LISI  can  be  used  at  any  point  the  JTF  crisis  “life  cycle”  to  help 
identify  and  mitigate  interoperability  problems.  This  application  may  be  repeated 
throughout  the  life  cycle  of  the  JTF  many  times  as  systems  and  nodes  come  and  go  within 
the  architecture.  Figure  4-4  below  depicts  the  process: 
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Figure  4-4.  LISI  Use  to  Assess  Interoperability  “On  the  Fly”,  from  (C4ISR,  1998) 


Step  1 :  JTF  planner  determines  which  systems  will  support  the  JTF.  Then,  the  JTF 
planner  retrieves  LISI  data  for  those  systems  from  the  LISI  data  repository. 

Step  2:  The  planner  builds  the  Potential  Interoperability  Matrix  for  all  of  the  systems  to 
evaluate  the  potential  of  each  of  the  systems  to  interoperate. 

Step  3  :  The  JTF  planner  builds  a  JTF  System  Interface  Description  (LISI  Overlay)  based 
on  JTF  operational  requirements  and  system  relationships.  The  foundation  of  the 
diagram  shows  the  mission’s  node-to-node  information  need  lines  and  required 
interoperability  levels.  The  diagram  then  “overlays”  the  supporting  systems  and  assesses 
where  the  LISI  level  of  interoperability  is  not  sufficient  to  satisfy  the  need  line 
requirements. 

Step  4  :  The  JTF  planner  can  evaluate  alternatives  by  modifying  the  interoperability 
profiles  of  the  systems  involved  and  re-running  the  analysis.  When  an  acceptable 
alternative  is  reached,  the  systems  can  be  modified,  if  practical,  to  change  their  interface 
characteristics  as  required  such  as  adding  an  Ethernet  card  to  a  machine  to  allow  it  access 
to  an  Ethernet  LAN.  Rapid  analysis  and  improvements  can  be  facilitated  by  LISI’s 
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process  and  augmented  by  an  appropriate  test  environment,  such  as  Joint  Battle  Center 
and  federated  laboratories. 

Given  the  need  to  make  disparate  systems  interoperate  in  a  short  time,  LISI  can 
help  a  JTF  planner  determine  the  following: 

•  Does  the  right  kind  of  interconnection  exist  between  systems? 

•  What  are  the  “critical'’  pathways? 

•  What  capabilities  need  to  be  deployed  to  augment  the  infrastructure  that  is  in 
place? 

•  Can  the  necessary  data  get  to  the  right  person  in  the  time  required? 

•  What  vulnerabilities  exist  with  respect  to  interoperability? 

•  What  additional  applications  are  needed  to  support  the  required  collaborative 
exchanges?  (C4ISR,  1998) 

5.  To  Support  Assessment  and  Certification 

LISI  can  also  be  used  to  support  the  assessment  and  certification  of  systems  and 
applications.  One  way  this  can  be  accomplished  is  by  using  LISI  data  submitted  with 
requirements  documents,  such  as  Mission  Needs  Statement  (MNS)  and  Operational 
Requirement  Document  (ORD)  for  a  new  program  in  the  preparation  of  the  Test  and 
Evaluation  Master  Plan  (TEMP).  The  approved  TEMP  would  include  LISI  assessment 
criteria  that  evaluate  a  system’s  interoperability  level.  The  results  of  these 
interoperability  evaluations  can  be  documented  in  the  test  reports.  For  example,  the  test 
report  could  show  that  System  X  is  certified  at  an  overall  interoperability  level  of  2a  and 
could  also  report  the  individual  P,  A,  I,  and  D  levels  (i.e.,  Procedures  =  2a,  Applications 
=  2b,  Infrastructure  =  2c,  and  Data  =  2c).  Figure  4-5  depicts  this  process. 
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Figure  4-5.  LISI  Use  to  Support  Systems  Assessment  and  Certification,  from 

(C4ISR,  1998) 


Step  1 :  LISI  data  for  the  system  to  be  certified  is  retrieved  from  the  LISI  database. 

Step  2:  A  Potential  Interoperability  Matrix  is  built  based  on  the  interoperability 
profiles  of  the  existing  and  planned  systems. 

Step  3:  Testing  is  conducted  to  ensure  that  all  systems  demonstrate  the 
interoperability  levels  specified  in  their  profiles. 

Step  4:  The  results  are  then  included  with  the  systems’  certification  documentation. 
(C4ISR,  1998) 

The  use  of  LISI  to  support  systems/application  assessment  and  certifications  is  most 
noteworthy.  Generally,  newly  developed  DOD  systems  are  to  be  denied  production 
approval  if  they  have  not  been  certified.  After  a  system  has  been  fielded  and  a 
modification  is  made  that  affects  interoperability,  the  system  must  be  re-certified.  A 
GAO  report  of  March  1998,  “Weaknesses  in  DOD’s  Process  for  Certifying  C4I  Systems’ 
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Interoperability,”  identified  several  weaknesses  in  the  certifying  process  (see  section 
2.3.4  for  more  information).  LISI  was  one  of  the  initiatives  mentioned  in  the  report  that 
would  improve  ways  of  complying  with  the  certification  process  and  would  lead  to 
resolution  of  many  of  the  issues  related  to  interoperability. 

C.  YES,  LISI  HAS  POTENTIAL  TO  IMPROVE  ARMY  SYSTEM 
INTEROPERABILITY 

In  support  of  the  ASEO  and  in  coordination  with  the  HTIO,  MITRE  Corporation 
conducted  the  Army  pilot  assessment  and  reported  in  November  1999  that  LISI  can 
improve  ABCS  interoperability.  This  assessment  was  conducted  by  applying  the  LISI 
prototype  to  various  interoperability  aspects  of  the  Army  Battle  Command  System 
(ABCS)  only.  The  report  indicated,  ‘‘The  findings  of  this  assessment  clearly  indicate 
how  the  LISI  process  provides  significant  added  value  towards  ASEO/HTIO’s  efforts  to 
improve  ABCS  interoperability.  The  collected  ABCS  systems  data  sufficiently 
demonstrated  the  LISI  methodology  and  Prototype  capabilities  that  are  now  available  for 
exploitation  by  ASEO/HTIO.”  (MITRE,  November  1999) 

1.  Background  of  the  LISI  Pilot  Assessment 

In  November  1999,  Army  System  Engineering  Office  (ASEO),  PEO  C3S 
Horizontal  Technology  Integration  Office  (HTIO),  and  MITRE  Corporation  completed  a 
joint  effort  in  assessing  LISI  using  components  of  the  Army  Battle  Command  System 
(ABCS).  The  assessment  effort  was  conducted  between  1  March  and  30  September  1999 
and  the  final  report  was  completed  in  November  1999. 

The  report  discusses  the  development  and  use  of  the  LISI  prototype  tool  in  its 
application  to  Army  Systems,  mainly,  the  eleven  highly  complex  ABCS  systems.  The 
eleven  systems  include  Advanced  Field  Artillery  Tactical  Data  System  (AFATDS),  Air 
and  Missile  Defense  Planning  and  Control  System  (AMDPCS),  All  Source  Analysis 
System  (ASAS),  Combat  Service  Support  Control  System  (CSSCS),  Digital  Topographic 
Support  System  (DTSS),  Force  XXI  Battle  Command  _  Brigade  and  Below  (FBCB2), 


62 


Global  Command  and  Control  System  -  Army  (GCCS-A),  Integrated  Meteorological 
System  (IMETS),  Integrated  System  Control  (ISYSCON),  Maneuver  Control  System 
(MCS),  and  Tactical  Airspace  Integration  System  (TAIS). 

The  report  of  the  pilot  assessment  recognized  that  its  data  might  not  be  complete, 
detailed  or  fully  validated:  “Since  the  current  ABCS  data  in  LISI  has  not  yet  been 
validated,  the  LISI  analysis  conducted  during  this  assessment  was  limited  to  providing 
initial  observation,  not  definite  conclusions,  regarding  ABCS  interoperability.” 

(MITRE,  1999)  Although  the  interoperability  profiles  and  matrices  produced  from  the 
assessment  might  not  reflect  the  true  interoperability  postures  among  the  eleven  systems 
at  the  time  during  the  pilot  assessment,  the  information  available  on  these  systems  was 
sufficient  to  demonstrate  the  LISI  methodology  and  prototype  capabilities  that  are  now 
available.  (MITRE,  1999) 

2.  Data  Analysis  from  the  Pilot  Assessment 

The  LISI  Prototype’s  analytical  capability  was  exercised  with  the  set  of  collected 
data.  LISI  Prototype  reports  were  examined  with  respect  to  (1)  their  inherent  value  in 
assessing  information  systems  interoperability,  and  (2)  specific  observations  for  ABCS 
component  interoperability.  Using  System  I  as  an  example,  the  following  paragraphs 
demonstrate  how  the  System  I  data  is  analyzed,  mapped  to  matrix  and  profile,  and  used 
for  identifying  shortfalls  and  recommending  remedies. 

a.  Generic  Interoperability  Profile 

It  maps  System  I’s  (a  single  system’s)  responses  to  the  questionnaire 
directly  to  the  LISI  Capabilities  Model.  This  mapping  forms  the  basis  for  determining  a 
system’s  generic  interoperability  level.  The  generic  interoperability  level  is  the  highest 
level  of  sophistication  at  which  a  system  could  generally  be  expected  to  interact  with  any 
other  system  in  an  environment  or  community.  The  generic  level  is  calculated  by 
examining  the  system  profile  from  the  bottom  up  and  determining  the  highest  level  at 
which  implementations  are  present  across  the  four  attributes,  P,  A,  I,  and  D.  Ligure  4-6 
shows  how  the  generic  interoperability  profile  for  System  I  is  summarized  as  “lc.” 
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Generic  Interoperability  Profile 
System  I  ABCS  6.0 

The  metric  for  System  I  is:  lc  (Pic  A4a  I3c  D2c) 
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Figure  4-6.  Example  Generic  Profile  for  System  I,  from  (MITRE,  1999) 

b.  Generic  Interoperability  Levels  (Reported  Level) 

They  are  summarized  in  Figure  4-7  below.  Waiving  JTA  compliance 
would  produce  the  indicated  “Waived’  level.  The  System  I  generic  interoperability  level 
of  “lc”  was  derived  from  the  generic  interoperability  profile  as  shown  in  Figure  4-6 
above. 
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ABCS  6.0  Systems 
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Figure  4-7.  Generic  LISI  Levels  Based  on  Reported  Capabilities,  from  (MITRE,  1999) 
c.  Interoperability  Assessment  Matrix 

It  was  derived  from  some  of  eight  complete  sets  of  ABCS  system  surveys 
and  as  shown  in  Figure  4-8  below.  The  boxes  are  colored  and  indicated  in  the  legend. 

To  prevent  the  indifference  of  the  colors  when  it  is  printed  in  black  and  white,  the  boxes 
are  also  indicate  the  color  by  a  capital  letter  corresponding  to  its  appropriate  legend,  that 
is,  B  for  Black,  G  for  Green,  L  for  Blue,  R  for  Red,  and  Y  for  Yellow  as  shown  below. 
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Figure  4-8.  ABCS  8- System  Interoperability  Assessment  Matrix,  from  (MITRE,  1999) 

This  matrix  indicates  major  gaps  or  significant  shortfalls  (red  conditions) 
for  5  system  pairs.  System  I-to-System  F  and  System  G-to-System  F  do  not  currently 
reflect  a  requirement  to  interact.  The  remaining  3  pairs  (System  A-to-System  G;  System 
I-to-System  A;  and  System  I-to-System  D)  have  interaction  limitations  identified  in  their 
respective  individual  interoperability  profiles. 

d.  Specific  Interoperability  Profiles 

It  is  used  to  examine  a  particular  interoperability  assessment  matrix  cell  in 
greater  detail  to  find  gaps  and  shortfalls,  and  to  indicate  solutions.  Attributes 
( Procedures ,  Applications,  Infrastructure ,  and  Data )  are  each  detailed  to  identify  specific 
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common  and  different  capabilities.  Specific  Interoperability  Profiles  were  generated  for 
one  of  the  ABCS  system  pairs:  one  of  the  “red”  conditions  (System  I-to-System  D). 
They  are  assessed  as  examples  of  how  the  LISI  profile  may  help  identify  and  resolve 
problems.  Figure  4-9  identifies  the  interoperability  levels  of  each  attribute  for  the 
following  system  pairs. 
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Infrastructure 

Data 

System  I-to- 
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Od 

lc 

3a 

Od 

2b 

Figure  4-9.  LISI  Interoperability  Levels  for  the  System  Pairs,  from  (MITRE,  1999) 

3.  Findings  from  the  Pilot  Assessment 

In  its  final  report  of  the  pilot  assessment,  MITRE  Corporation  concluded  that 
application  of  the  LISI  Prototype  demonstrates  LISI’s  potential  utility  in  making  useful 
insights  in  improving  interoperability  of  Army  systems.  For  ASEO  and  HTIO,  LISI 
presented  profiles  of  the  current  ABCS  components  at  a  level  of  detail  sufficient  to: 

•  Discern  the  level  of  sophistication  at  which  the  ABCS  components  could 
potentially  interact. 

•  Define  the  nature  of  that  interaction. 

•  Characterize  the  capability  improvements  in  each  program,  such  as  adding 
mapping  or  office  automation  to  the  applications,  adding  infrastructure 
capabilities,  or  adopting  of  domain  data  models. 

•  Provide  a  perspective  for  requirement-based  interoperability  assessments,  such  as 
providing  AFATDS  Interface  Control  Document  (ICD)  view  versus  AFATDS 
PMO  view. 

The  findings  of  this  assessment  clearly  indicate  that  the  LISI  process  provides 
significant  added  value  towards  ASEO  and  HTIO’s  efforts  to  improve  ABCS 
interoperability  (MITRE,  1999). 
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D.  BUT,  THE  CURRENT  LISI  TOOL  HAS  TO  BE  REFINED  AND 
UPGRADED 

PEO  C3S  HTIO  was  tasked  by  Directorate  of  Integration  (DOI)  to  provide 
suggestions  for  improvements  to  the  LISI  questionnaire  and  associated  reports.  In 
September  2001,  HTIO  submitted  a  LISI  Linal  Report  and  Analysis  to  DOI.  The  primary 
source  of  the  data  for  this  evaluation  covers  DOI- selected  ABCS  systems.  (Paterson, 
2000)  The  PEO  C3S  HTIO  also  manages  this  data  collection.  In  the  report,  HTIO 
indicated  that  there  are  deficiencies  in  the  LISI  tool,  particularly  in  the  on-line 
questionnaire,  and  refinement  and  upgrade  of  LISI  tool  is  needed.  The  following 
discussions  include  some  examples  of  the  findings  and  recommendations  from  HTIO 
assessment. 

1.  Expand  the  Question  and  Answer  Choices 

•  Under  (Attributes/Procedures)  the  question  entitled  Operating  Environment 
Types,  there  are  more  environments  than  the  choices  would  indicate,  need  to  have 
an  add-in  box  to  accommodate. 

•  Under  question  Document  Exchange  Lormats,  we  need  an  expanded  dropdown 
list  box. 

•  Under  question  Operation  Networks,  answer  choices  provided  are  not  adequate  or 
comprehensive  enough.  Lor  example,  there  is  no  Tactical  Internet  Upper  or 
Tactical  Internet  Lower  operational  network  as  the  Army  uses.  Additionally, 
these  questions  must  have  fill-in  boxes  because  explanations  are  critical  to  explain 
particular  system  hardware  set-ups  within  their  infrastructure.  (Stubins,  2001) 

2.  Clear  Ambiguous  and  Misleading  Questions 

•  There  is  quite  a  bit  of  confusion  concerning  the  exact  definition  of  the  differences 
between  the  JVML  messages  and  the  (old)  VML  messages.  Exactly  what  it  meant 
by  when  asking  if  a  user  uses  (old)  VML  messages. 
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•  Under  Removable  Media,  what  are  we  looking  for,  the  device  itself?  Or  the 
media  in  the  device? 

•  Under  question  Security  Measures,  this  question  needs  to  be  tightened  up 
considerably.  There  are  numerous  categories  security  measures  fall  under.  This 
is  another  case  of  the  question  meaning  anything  the  user  wants  it  to  mean. 

•  Throughout  the  questionnaire  users  are  asked  whether  or  not  items  are  available 
and  if  they  are  required.  The  question  of  what  is  and  isn’t  required  falls  outside 
the  goals  of  the  LISI  questionnaire.  Questioning  the  users  requirements  only 
serves  to  feed  the  users  insecurities  about  hidden  agendas.  (Stubins,  2001) 

3.  Require  knowledgeable  Person  to  Input  LISI  Data 

Garbage  in  and  garbage  out,  the  LISI  output  for  the  interoperability  assessment 
and  improvement  are  only  as  good  as  the  data.  LISI  tool  uses  the  Interoperability 
Questionnaire  to  collect  the  pertinent  information  through  the  web-based  Inspector 
version  1.0.  The  questionnaire  is  linked  to  the  LISI  models  and  tables  that  comprise  the 
assessment  basis. 

Inspector  currently  contains  approximately  220  questions  composed  of  over 
12,000  individual  response  choices.  Each  field  checked  for  every  question  eventually 
will  lead  to  a  profile  decision-making.  The  person  inputting  the  data  needs  to  be 
thoroughly  knowledgeable  about  the  C4I  system  itself,  to  know  how  to  use  the  LISI  tool, 
and  to  properly  fill  out  each  of  the  questionnaire  for  useful  analysis. 

4.  Concentrate  on  Fewer  Reports  with  the  Highest  Quality 

In  the  second  assessment  report,  HTIO  indicated  LISI  test  outcomes  depend  on 
algorithms  that  are  unknowns  to  the  world  outside  the  coder.  It  is  difficult  if  not 
impossible  to  intelligently  comment  on  “black  boxed”  report  outcomes  without 
possessing  knowledge  of  the  processes  that  are  driving  the  report  outcomes.  HTIO  also 
recommended  that  the  entire  LISI  report  structure  requiring  replacement  with  a  modem, 
customer- centric  design.  A  requirements  description  detailing  the  necessary  reports 
needs  to  be  written.  (Stubins,  2001) 
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E.  PROVIDE  FUNDING  AND  RESOURCES  TO  UPGRADE  LISI 


HTIO,  PEO  C3S  has  been  the  Army  lead  in  LISI  efforts.  After  the  pilot 
assessment,  HTIO  recognized  the  need  for  LISI  continuing  improvement  and  submitted  a 
Rough  Order  of  Magnitude  (ROM)  estimate  on  21  October  1999  to  request  for  funding  in 
the  amount  of  over  $800,000.  (PEO  C3S,  1999)  The  estimate  was  to  fund  manpower 
and  training  for  Database  Logical  Design  and  Physical  Schema,  System/Server 
Architecture  and  Interface  Design,  Application  Design  and  Development,  Database 
Initialization,  and  Training.  In  addition,  the  funds  are  needed  to  purchase  three  servers 
with  workstations  for  System  Development  Environment,  Web  application  development 
tools,  SQL  Server  Development  Environment,  MS  Developers  Kit,  VB  Development 
Environment,  ERWin,  and  NetVis  or  VISIO  for  output  graphics,  etc.  However,  the 
funding  was  never  approved. 

To  correct  the  deficiencies  as  discussed  above  will  cost  money,  therefore,  funding 
and  resources  should  be  property  allocated.  Also,  “Interoperability  is  an  ideal  condition 
that  can  be  approached  but  never  totally  achieved  because  of  the  dynamic  nature  of 
military  operations,  system  acquisition,  and  technology  improvements.”  (JITC,  2001) 
Therefore,  the  continuing  of  LISI  evolution  and  maintenance  is  unavoidable  and  the 
funding  to  continue  the  enhancement  and  maintenance  of  LISI  is  essentially  required. 

F.  CHAPTER  SUMMARY 

After  the  data  about  the  existing  and  developing  systems  have  been  registered 
using  the  LISI  Interoperability  Questionnaire  and  are  stored  in  a  repository  or  database 
for  easy  access,  LISI  can  provide  a  quantitative  interoperability  assessment  for  Program 
Managers  (PMs)  and  system  developers  to  assess  their  program  interoperability  during 
the  entire  system  life  cycles.  LISI  can  be  used  in  developing  interoperability  requirement 
for  a  new  system.  It  can  improve  interoperability  of  an  existing  system/application.  It 
can  be  used  as  an  interoperability  tool  for  command  architects.  It  can  be  used  for 
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interoperability  “on  the  fly.”  Also,  it  can  be  used  to  support  interoperability  assessment 
and  certification. 

MITRE  Corporation  concluded  in  its  1999  assessment  for  HTIO  that  application 
of  the  LISI  Prototype  demonstrated  LISI’s  potential  utility  in  making  useful  insights  into 
C4I  Systems  for  improving  interoperability  of  Army  systems.  It  also  clearly  indicated 
that  the  LISI  process  provides  significant  added  value  towards  ASEO  and  HTIO’s  efforts 
to  improve  ABCS  interoperability  (MITRE,  1999). 

However,  in  the  2001  assessment,  HTIO  indicated  that  the  current  LISI  tool 
needed  to  be  refined.  The  choices  of  questions  and  answers  need  to  be  expanded. 
Ambiguous  questions  have  to  be  cleared  or  avoided.  LISI  data  has  to  be  input  by  persons 
knowledgeable  in  both  the  C4I  systems  and  LISI  tool.  Reports  produced  should  only  be 
high  quality  and  meaningful.  To  correct  the  above  deficiencies  will  cost  money  and 
should  be  funded.  Also,  the  resources  should  be  provided  to  upgrade,  to  operate,  to 
maintain,  and  to  continue  the  evolution  and  enhancement  of  the  LISI  system. 

To  answer  the  prime  thesis  question,  as  whether  LISI  can  improve  the  C4I 
systems’  interoperability,  the  answer  is  that  LISI  has  potential  to  improve  DOD  C4I 
systems’  interoperability,  but  the  current  LISI  tool  has  to  be  refined  and  upgraded. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  SUMMARY 

The  military  services  have  a  long  history  of  interoperability  problems  during  joint 
operations.  The  success  of  the  Persian  Gulf  War  in  1991  was  hampered  by  a  lack  of 
basic  interoperability.  Since  then,  the  DOD  has  had  a  number  of  initiatives  to  address 
various  aspects  of  interoperability,  such  as  Joint  Tactical  Architecture  (JTA),  Defense 
Information  Infrastructure  (DII)/Common  Operating  Environment  (COE),  DII  Master 
Plan,  Shared  Data  Environment  (SHADE),  Joint  Battle  Center  (JBC),  and  Joint 
Interoperability  Test  Command  (JITC).  Among  these  initiatives,  LISI  is  the  key  tying  all 
the  initiatives  together. 

Commencing  in  1993,  MITRE  Corporation  has  been  the  developer  for  LISI 
process  and  its  associated  software  applications  and  LISI  has  continued  to  advance  in 
capability  through  several  evolutions:  The  Exploratory  Phase  in  1994,  Analysis  Phase  in 
1996,  Proof  of  Concept  Phase  in  1997,  Development  Phase  and  pilot  assessment  in  1999, 
culminated  in  the  mandatory  use  of  LISI  in  2000.  The  1999  Development  Phase  was 
accelerated  as  the  result  of  the  GAO  report  entitled:  Joint  Military  Operations: 
Weaknesses  in  DOD’s  Process  for  Certifying  C4I  Systems’  Interoperability.”  A  pilot 
assessment  of  LISI  using  components  of  ABCS  was  conducted  by  MITRE  Corporation  in 
1999.  The  mandate  of  LISI  use  was  directed  on  15  August  2000.  And  the  final  report  of 
the  second  assessment  by  HTIO  was  submitted  on  28  September  2001. 

My  personal  interest  in  the  area  of  information  system  interoperability  started  in 
August  1997  when  I  worked  in  the  HTIO,  PEO  C3S,  which  manages  fifty-plus  mission 
critical  C3S  systems  and  has  been  designated  as  the  Army  lead  in  the  LISI  efforts.  I 
continue  to  have  the  firsthand  information  on  LISI  progress  even  after  moving  to  PM 
TRCS,  one  of  PEO  C3S  PM  offices,  in  October  2000.  My  associate  thesis  advisor,  Mr. 
Tony  Kunsaitis,  is  the  Interoperability  Manager  for  PEO  C3S.  Mr.  Kunsaitis  has 
introduced  me  to  the  wonder  world  of  the  information  system  interoperability  and  the 
progress  of  LISI  development. 
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Although  LISI  was  initiated  in  1993,  it  is  still  foreign  to  the  majority  of  the 
program  management  community  even  today.  I  had  originally  planned  for  my  thesis  to 
show  how  the  LISI  can  help  PMs  and  hoped  to  convince  them  to  use  LISI.  When  the  use 
of  LISI  became  mandatory  in  August  2000, 1  changed  my  thesis  concentration  on 
whether  LISI  can  improve  C4I  systems  interoperability. 

In  order  to  examine  how  LISI  can  improve  DOD  C4I  systems’  interoperability, 
detailed  explanation  of  the  LISI  system  itself  was  discussed  in  both  Chapters  II  and  III. 
Chapter  II  provided  the  overview  of  LISI,  its  definition,  elements,  and  associated  process. 
It  also  introduced  the  motivations  for  LISI  initiation  and  implementation.  Chapter  III 
illustrated  how  LISI  is  applied,  its  security,  and  its  user  friendliness.  Much  of  the 
background  information  was  referenced  from  the  C4ISR  Architectures  Working  Group’s 
LISI  report  of  30  March  1998. 

Chapter  IV  answered  the  prime  research  question  as  to  whether  LISI  can  improve 
C4I  interoperability.  The  concept,  theory,  mythology,  the  application  and  use  of  the  LISI 
process,  and  the  results  from  the  two  LISI  assessments  led  to  the  conclusion  of  this  thesis. 
The  conclusions  made  in  this  thesis  that  LISI  can  improve  the  information  system 
interoperability  are  based  on  the  research  available  as  of  this  writing  and  is  summarized 
in  the  following  section. 

B.  CONCLUSIONS  TO  RESEARCH  QUESTIONS 

1.  What  Is  LISI? 

LISI  is  a  formal  Reference  Model,  an  assessment  implementation  of  the 
interoperability  maturity  model,  and  a  structured  process  for  improving  interoperability 
between  varied  information  system.  The  LISI  tool  provides  an  automated,  web-based 
interoperability  assessment  capability.  The  heart  of  the  LISI  concept  is  the  formulation 
of  a  system  ’’profile,”  which  was  created  by  LISI  web-based  tool,  Inspector  1.0.  The 
“profile”  may  become  the  common  denominator  for  determining  interoperability  between 
C4  systems  but  it  certainly  not  a  prescription  for  guaranteeing  interoperability. 
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Therefore,  LISI  is  a  tool  and  process  to  assess  and  measure  but  not  to  guarantee  the 
interoperability  of  information  systems. 

2.  What  Are  Central  Elements  of  LISI  And  Associate  Process? 

The  LISI  process  focused  on  defining  and  assessing  systems  against  increasing 
levels  of  sophistication  for  system- to- system  interaction.  The  process  defines  thresholds 
of  capabilities  that  a  system  exhibits  as  it  improves  and  matures  in  its  ability  to  interact 
with  other  systems.  These  thresholds  become  levels  of  interoperability  that  can  be 
measured  consistently  throughout  the  system’s  life  cycle.  LISI  also  categorized  the 
various  aspects  of  information  systems  interoperability  in  terms  of  four  comprehensive 
and  closely  interrelated  attributes.  Therefore,  the  “Levels”  and  the  “Attributes”  are  the 
essential  elements  of  LISI.  LISI  considers  five  increasing  levels  of  sophistication  with 
respect  to  exchanging  and  sharing  information  and  services.  Each  higher  level  represents 
a  demonstrable  increase  in  capabilities  over  the  previous  level  of  systemto-system 
interaction.  This  increase  is  expressed  in  terms  of  the  PAID  attributes  -  the  Procedures 
imposed  by  information  management,  the  capabilities  of  Applications  that  act  on  that 
data,  the  type  of  Infrastructure  required,  and  the  nature  of  Data  transferred. 

3.  What  Are  the  Motivations  to  Implement  LISI? 

•  To  Achieve  Information  Superiority:  LISI  was  initiated  in  1993  after  the 
difficulties  of  basic  interoperability  experienced  during  the  Persian  Gulf  War  in 
1991.  The  Information  Superiority  envisioned  by  the  Chairman  of  the  Joint 
Chiefs  of  Staff  in  his  Joint  Vision  2010  in  1997  further  challenged  the 
development  and  implementation  of  LISI. 

•  To  Support  Joint  Task  Lorce:  Although  the  DOD  Joint  Task  Forces  does  not 
exist  until  the  need  arises,  it  is  crucial  to  have  existed  quick  access  and  ready 
information  whenever  the  need  arises  to  bring  together  the  supporting  systems, 
which  need  to  be  interoperate  at  the  requisite  levels.  LISI  can  be  used  at  any 
point  the  JTF  crisis  “life  cycle”  to  help  identify  and  mitigate  interoperability 
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problems.  This  application  may  be  repeated  throughout  the  life  cycle  of  the  JTF 
many  times  as  systems  and  nodes  come  and  go  within  the  architecture. 

•  To  Comply  with  Information  Technology  Management  Reform  Act:  The 
ITMRA  of  1996  requires  the  Federal  Government  to  develop  “a  process  and 
procedure  for  establishing  goals  for  improving  the  efficiency  and  effectiveness  of 
government  agencies”  operations  and  the  ability  to  deliver  goods  and  services  to 
the  public  using  information  technology.  The  goals  must  be  measurable.”  Prior 
to  LISI,  there  were  no  widely  accepted  performance-based  and  results-based 
standards  for  interoperability.  Now  LISI  directly  supports  the  development  of  IT 
architectures  within  the  context  of  ITMRA  by  assessing  the  level  of 
interoperability  required  and  attained  between  systems. 

•  To  Assist  in  Certifying  Process  and  Improving  C4I  Systems” 
Interoperability:  GAO  identified  several  weaknesses  in  DOD’s  process  for 
certifying  C4I  systems”  interoperability  in  its  March  1998  report  and 
recommended  that  a  number  of  interoperability  improvement  initiatives  had  to  be 
continued.  LISI  was  one  of  the  initiatives  recommended  in  the  report.  GAO  also 
indicated  “DOD’s  1993  LISI  initiative  is  to  improve  C4  and  intelligence  systems’ 
interoperability.  System  developers  are  to  use  this  tool  to  assess  interoperability, 
to  determine  capabilities  needed  to  support  system  development,  and  to  determine 
the  degree  of  interoperability  needed  between  C4I  and  other  systems.” 

•  To  Become  a  Mandatory  Interoperability  Evaluation  Tool:  The  Director  of 
Information  System  for  C4  and  the  Military  Deputy  to  the  Assistant  Secretary  of 
the  Army  (AL&T)  mandated  on  their  joint  memorandum  of  19  August  2000  that 
the  HQDA  to  employ  LISI  framework  and  its  associated  interoperability 
assessment  tool  to  address  SoS  interoperability.  The  rationale  was  that  the 
technical  data  stored  in  LISI  along  with  LISI  output  products  satisfy  the  C4ISP 
requirements  for  a  technical  architecture  profile  and  view. 
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4.  How  Does  LISI  Process  Work? 

LISI  uses  the  LISI  Survey  through  a  web-based  tool,  Inspectorl.O  to  collect  the 
pertinent  information  required  to  assess  information  systems  interoperability.  User 
register  system  characteristics  by  selecting  the  appropriate  responses  to  the  questions  and 
then  the  answers  are  stored  in  a  table  from  which  data  are  used  to  create  a  set  of  reports. 

The  information  collected  from  the  LISI  Survey  is  consolidated  and  presented  by 
subject  area  and  is  mapped  into  five  LISI  levels  (zero  through  four)  and  in  terms  of  four 
LISI  attributes  (P,  A,  I,  and  D).  The  detailed  information  is  overlaid  on  the  LISI 
Capabilities  Model  to  form  the  system’s  Interoperability  Profile.  The  LISI  Capabilities 
Model  and  its  supporting  LISI  Options  Tables  together  constitute  the  “engine’  that  drives 
the  LISI  process  and  provide  the  basis  for  developing  the  LISI  products. 

LISI  Inspector  leverages  the  data  captured  in  the  questionnaire  to  generate  four 
primary  sets  of  assessment  products:  Interoperability  Profiles,  Interoperability 
Assessment  Matrices,  Interoperability  Comparison  Tables,  and  Interoperability  System 
Interface  Description.  Each  set  of  products  differs  in  its  presentation,  the  intended  use, 
and  interoperability  aspect  it  considers. 

5.  Is  the  LISI  System  Secure? 

LISI  data  privacy  is  considered  highly  protected  for  all  systems  registered  in  LISI. 
There  are  several  control  points  that  would  demonstrate  this  high  level  of  protection: 

•  Deputy  Chief  of  Staff  for  Operations  who  manage  the  system  configuration  and 
has  the  ownership  rights  and  report  access. 

•  Program  Managers,  Systems  Managers  or  their  delegates  input  the  data. 

•  The  LISI  data  access  is  web  based  and  certain  software  and  hardware  are 
required. 

•  Access  to  LISI  System  Data  Repository  is  password  protected.  Each  user  requires 
a  user- ID,  password,  and  domain  name. 

•  A  System  Administrator  for  each  of  the  Services  controls  the  passwords. 

•  Each  Program  Manager  or  Systems  Manager  can  decide  the  level  of  information 
release  by  registering  the  system  as  “Private,”  “Local,”  or  “Global.” 
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6.  Is  the  LISI  System  User  Friendly? 

The  LISI  Inspector,  a  web-based  tool,  was  designed  to  provide  a  C4I-wide  user- 
friendly  process  for  determining  interoperability  needs.  The  questionnaire  information 
collected  in  the  Inspector  is  presented  in  a  user-friendly  Hyper  Text  Markup  Language 
(HTML)  format,  and  is  captured  through  an  administrative  HTML  interface. 

The  LISI  Inspector  completed  a  series  of  major  enhancements  during  FY  99  to 
make  the  application  of  LISI  Inspector  more  user-friendly  and  meaningful.  Although  the 
questionnaires  currently  contain  over  220  questions  covering  3,000  possible  answers  with 
over  12,000  individual  response  fields,  any  one  system  normally  has  to  answer  only  a 
small  subset  of  these  questions.  The  questionnaire  is  organized  hierarchically  so  that 
only  those  questions  that  relate  to  the  capabilities  being  registered  for  the  system  need  to 
be  answered. 

The  three- levels  of  data  information  release  is  another  user-friendly  feature.  The 
data  input  can  remain  at  “Private”  level  before  the  system  manager  or  program  manager 
reviews  and  determines  that  the  data  input  for  the  system  is  accurate  and  complete.  Also, 
the  users  can  “Print  Survey”  to  review  the  input  before  re- classifying  the  information  to 
the  next  level  or  choose  to  print  the  “whole  survey’  or  “one  attribute”  at  a  time. 

7.  Can  LISI  Improve  DOD  C4I  Systems’  Interoperability? 

The  answer  is  a  “yes,  but  ...”  Yes,  LISI  has  potential  to  improve  Army  systems 
interoperability  but  current  LISI  tool  need  to  be  refined  and  upgraded. 

LISI  was  initiated  in  1993  and  designed  and  evolved  to  comply  with  the 
Information  Technology  Management  Reform  Act  of  1996  to  develop  a  process  and 
procedure  for  information  technology  and  to  improve  system  interoperability.  A 
prototype  assessment  of  the  LISI  using  components  of  the  ABCS  was  used  to 
demonstrate  how  LISI  could  be  used  to  improve  interoperability.  MITRE  in  its  final 
report  of  the  pilot  assessment  clearly  indicated  that  the  LISI  process  provides  significant 
added  value  towards  ASEO  and  HTIO’s  efforts  to  improve  ABCS  interoperability. 

HTIO  reported  in  September  2001  from  the  second  assessment  that  the  LISI  tool 
has  many  deficiencies  and  need  to  be  refined  and  upgraded.  The  choices  of  questions  and 
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answers  need  to  be  expanded.  Ambiguous  questions  have  to  be  cleared  or  avoided.  LISI 
data  has  to  be  input  by  persons  who  are  knowledgeable  in  both  the  C4I  system  and  the 
LISI  tool.  Reports  produced  should  only  be  high  quality  and  meaningful.  Also,  the 
resources  should  be  provided  to  upgrade,  to  maintain,  and  to  continue  the  evolution  and 
enhancement  of  the  LISI  system. 

C.  RECOMMENDATIONS  FOR  FURTHER  STUDY 

The  further  study  may  include  but  not  limited  to  the  following  areas: 

•  LISI  Management  Support:  The  mandate  of  LISI  in  August  2000  appeared  not  to 
have  gotten  the  attention  of  all  levels  of  management.  As  of  today,  LISI  is  still 
foreign  to  most  of  the  program  management  community.  Further  study  may 
explore  the  reasons  for  this  drawback  and  provide  recommendation  for 
improvement. 

•  LISI  Funding  Resources:  As  discussed  in  section  4.4.5,  the  continuing  of  LISI 
evolution  and  maintenance  is  unavoidable  and  the  funding  to  continue  the  LISI 
enhancement  and  refinement  is  essentially  required.  Further  study  may  discuss 
where  the  continuing  funding  should  be  resourced. 

•  LISI  Tool  Advertising:  LISI  is  using  the  Inspector  1.0,  a  web-based  tool,  to 
capture,  manipulate,  analyze,  and  report  interoperability  assessment.  The  tool  is 
effective,  rather  secure,  and  user-friendly  although  it  requires  further  refinement 
and  upgrade.  However,  the  tool  is  still  foreign  to  the  majority  of  the  program 
management  community  as  of  today  regardless  the  fact  that  LISI  was  initiated  in 
1993.  In  order  to  expand  the  user  population  more  advertising  and  training  efforts 
are  required.  Therefore,  how  to  sell  the  tool  might  be  an  area  for  further  study. 

•  LISI  Data  Accuracy  Assurance:  Garbage  in  and  garbage  out,  the  LISI  output  for 
the  interoperability  assessment  and  improvement  are  only  as  good  as  the  data.  In 
addition  to  having  the  knowledgeable  person  input  the  data,  the  possible 
mechanisms  to  coordinate  and  trigger  the  updates  of  database  will  be  an  added 
value  to  the  LISI  system  and  should  be  explored. 
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•  LISI  Continuing  Evolution  and  Enhancement:  LISI  has  come  a  long  way  to 
today’s  pilot  assessments.  It  has  evolved  since  its  inception  in  1993.  Each 
evolution  refines  and  enhances  the  LISI  system  and  should  be  continued.  Further 
study  should  be  continued  to  assess  the  current  LISI  system  and  application  and  to 
recommend  ways  for  improvement. 

•  Validation  of  LISI  Usefulness  Based  on  GAO  Recommendations :  GAO 
identified  several  weaknesses  in  DOD’s  process  for  certifying  C4I  systems’ 
interoperability  in  its  March  1998  report.  It  also  endorsed  LISI  initiative  in  the 
report  and  recommended  that  system  developers  use  LISI  for  assessing 
interoperability,  determining  capabilities  needed,  and  determining  the  degree  of 
interoperability  needed  between  C4I  and  other  systems.  After  the  LISI 
implementation  becomes  C4I  system  wide,  a  further  study  should  be  conducted  to 
show  if  and  how  LISI  can  improve  the  deficiencies  identified  in  the  GAO  report. 

In  its  final  report  of  the  Pilot  Assessment  of  LISI  Using  Components  of  the 
ABCS,  ASEO  and  HTIO  anticipated  that  a  “joint’  interoperability  assessment  would  be 
feasible  in  early  FYOO.  As  of  this  writing,  the  anticipation  was  overly  optimistic, 
therefore,  the  findings  from  the  Pilot  Assessment  of  ABCS,  which  are  only  part  of  the 
C4I  systems,  were  used  to  derive  the  conclusions.  Further  study  should  be  conducted  as 
soon  as  the  “joint”  interoperability  assessment  is  made  possible  and  all  the  C4I  systems 
are  included  in  the  database. 

Interoperability  is  an  ideal  condition  that  can  be  approached  but  never  totally 
achieved  because  of  the  dynamic  nature  of  military  operations,  system  acquisition,  and 
technology  improvements.  Therefore,  the  continuing  of  LISI  evolution  and 
enhancements  is  unavoidable.  It  is  my  sincere  desire  that  the  above-recommended  areas 
be  further  studied,  ways  to  enhance  LISI  system  can  be  implemented,  improvements  on 
C4I  system  interoperability  can  be  realized  on  a  continuing  basis,  and  collectively,  we 
can  achieve  the  information  Superiority  envision  by  Joint  Vision  2010. 
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APPENDIX  A  -  ACRONYMS  AND  ABBREVIATIONS 


A&T 

ABCS 

AEGIS 

AFTDS 

AIMIS 

AMC 

AMDWS 

ASAS 

ASD 

ASEO 

AWG 

BCC 

BMDO 

CCB 

CDG 

CECOM 

CIPO 

COE 

csscs 

C2 

C3I 

C3S 

C4I 

C4ISP 

C4ISR 


DA 

DAMO 

DCSOPS 

DII 

DISA 

DOD 

DOI 

DTSS 

ESC 

FBCB2 

FDD 


Acquisition  and  Technology 

Army  Battle  Command  and  Control  Systems 

Airborne  Early  Waming/Ground  Environment  Integration  Segment 

Advanced  field  Artillery  Tactical  Data  System 

Army  Interoperability  Management  Information  System 

Army  Materiel  Command 

Air  and  Missile  Defense  Workstation 

All  Source  Analysis  System 

Assistant  Secretary  of  Defense 

Army  System  Engineering  Office 

Architectures  Working  Group 

Biological  Chemical  Command 
Ballistic  Missile  Defense  Office 

Configuration  Control  Board 
Competitive  Development  Group 
Communications  and  Electronics  Command 
C4ISR  Interoperability  Program  Office 
Common  Operating  Environment 
Combat  Service  Support  Control  System 
Command  and  Control 

Command,  Control,  Communications,  and  Intelligence 
Command,  Control,  and  Communications  Systems 
Command,  Control,  Communications,  Computers,  and  Intelligence 
C4I  Support  Plan 

C4I  Surveillance  and  Reconnaissance 


Department  of  Army 

DA  Military  Office  (Office  of  Deputy  Chief  of  Staff  for  Operations) 

Deputy  Chief  of  staff  for  Operations 

Defense  Information  Infrastructure 

Defense  Information  Systems  Agency 

Department  of  Defense 

Directorate  of  Integration 

Digital  Topographic  Support  System 

Electronic  Systems  Center 

Force  XXI  Battle  Command  -  Brigade  and  Below 
First  Digital  Division 
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GAO 

General  Accounting  Office 

GCSS-A 

Global  Combat  Support  System  -  Army 

HQDA 

Headquarters,  Department  of  the  Army 

HTIO 

Horizontal  Technology  Integration  Office 

HTML 

Hyper  Text  Markup  Language 

IAP 

Integrated  Architectures  Panel 

I&RTS 

Integration  and  Runtime  Standards 

ICD 

Interface  Control  Document 

IF 

Intelligence  Fusion 

IMETS 

Integrated  Meteorological  System 

IOC 

Initial  Operational  Capability 

IP 

Internet  Protocol 

ISC 

Intelligence  Systems  Council 

ISO 

International  Standard  Organization 

ISYSCON 

Integrated  Systems  Control 

IT 

Information  Technology 

Internet  Protocol 

ITF 

Integration  Task  Force 

ITMRA 

Information  Technology  Management  Reform  Act 

JBC 

Joint  Battle  Center 

JCPAT 

Joint  C4  Program  Assessment  Tools 

JITC 

Joint  Interoperability  Test  Command 

JS 

Joint  Staff 

JTA 

Joint  Technical  Architecture 

JTF 

Joint  Task  Force 

JULLS 

Joint  Universal  Lessons  Learned  Systems 

JWICS 

Joint  Warfare  Intelligence  Center 

LISI 

Levels  of  Information  Systems  Interoperability 

MCS 

Maneuver  Control  System 

MARCORSYSCOM 

Marine  Corps  Systems  Command 

MNS 

Mission  Needs  Statement 

NIPRNET 

Non- Secure  Internet  Protocol  Network 

ORD 

Operational  Requirements  Document 

OSD 

Office  of  the  Secretary  of  Defense 

OSI 

Open  Systems  Interconnection 
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PAID 

PEO 

PM 

PMO 

Procedures,  Applications,  Infrastructure,  and  Data 
Program  Executive  Office 

Program  Manager 

Program  management  Office 

QDR 

Quadrennial  Defense  Review 

RMA 

ROM 

Revolution  in  Military  Affairs 

Rough  Order  of  Magnitude 

SA 

SHADE 

SIPRNET 

SM 

SoS 

STAMIS 

System  Administrator 

Shared  Data  Environment 

Secure  Internet  Protocol  Network 

System  Manager 

System- Of- Systems 

Standard  Army  Management  Information  System 

TACOM 

TAIS 

TBMCS 

TCP 

TEMP 

TM 

Tank  Automotive  Command 

Tactical  Airspace  Integration  System 

Theatre  Maritime  Battle  Management  Core  System 
Transmission  Control  Protocol 

Test  and  Evaluation  Master  Plan 

Theater  Missile 

UCAO 

USD 

USMTF 

Unified  Cryptology  Architecture  Office 

Under  Secretary  of  Defense 

US  Message  Text  Format 

VCJCS 

Vice  Chairman  of  the  Joint  Chiefs  of  Staff 
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